 1-Oct-85 05:47:05-MDT,1131;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 1 Oct 85 05:47:01-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a018220; 1 Oct 85 7:14 EDT
Received: from usenet by TGR.BRL.ARPA id a020540; 30 Sep 85 20:01 EDT
From: Melinda Shore <shor%sphinx.uchicago.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: wanna buy TurboPascal for CP/M-80
Message-ID: <1148@sphinx.UChicago.UUCP>
Date: 27 Sep 85 20:39:46 GMT
To:       info-cpm@AMSAA.ARPA

[]
Try the Programmer's Shop in Massachusetts.  I've had uniformly
excellent experiences buying my software from them.  They claim to
carry every programmer's tool for CP/M, MS-DOS, and MacIntosh
computers.

	Programmer's Shop
	128 Rockland St.
	Hanover, MA  02339
	800-421-8006

I don't know their price for Turbo Pascal, but I know they've got it.

[I'm not affiliated with the Programmer's Shop]

-- 
Melinda Shore                               ..!ihnp4!gargoyle!sphinx!shor
University of Chicago Computation Center    Staff.Melinda%chip@UChicago.Bitnet

"Beavers, by teamwork family life!"    [Dr. Bronner]
 1-Oct-85 06:10:08-MDT,1815;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 1 Oct 85 06:10:00-MDT
Received: from ames-vmsb.arpa by AMSAA.ARPA id a018491; 1 Oct 85 7:24 EDT
Date: 30 Sep 85 16:57:00 PST
From: nep.pgelhausen@AMES-VMSB.ARPA
To: info-cpm@AMSAA.ARPA
Reply-To: nep.pgelhausen@AMES-VMSB.ARPA

I tried sending this directly, but the net wasn't taking UCHICAGO
in the path....oh well, in reply to:

> From: Stuart Schmukler <sas1%sphinx.uchicago.uucp@BRL.ARPA>
> Subject: BREAK on Osborne I
> 
> Does anyone have code that generates a BREAK for the Osborne I?
> 
> I have tried unsuccessfully to add code to Osborne I Kermit to generate a
> BREAK.  I thought since the Apple ][ CCS 7710A card uses a memory mapped
> 6850, that similar code should work on the Osborne I.  But of course :-) it
> does not work.
> 
> Are there any Osborne Wisards out there that can help?
> 
> SaS


The break signal is merely a sustained SPACE signal in the RS-232
connection.  (SPACE referring to the MARK/SPACE (1/0) distinction,
not the ascii 32 space code...)  If you have direct access to the
lines on the RS-232 port on your osborne from software, you can
create a small routine to pull this line down for a short period.

Normally the port carries a MARK signal, broken by a SPACE then
8 bits of ascii code w/ 1 or two stop bits.

I may have my usage of MARK & SPACE reversed.  It could be carrying
the SPACE normally, requiring a sustained MARK to use as BREAK.  See
your systems documentation on RS-232 port usage (if any....).

Hope this helps,
			-Richard Hartman
			max.hartman@ames-vmsb

P.S.: as long as I am sending this to the net in general, could
      anyone post the actual mechanics of what I was *trying* to
      explain?
			-rmh
------
 1-Oct-85 06:25:22-MDT,676;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 1 Oct 85 06:25:16-MDT
Received: from washington.arpa by AMSAA.ARPA id a018718; 1 Oct 85 7:31 EDT
Date: Mon 30 Sep 85 18:04:18-PDT
From: Ronald Blanford <CONTEXT@WASHINGTON.ARPA>
Subject: Bulletin boards
To: info-cpm@AMSAA.ARPA

I am looking for programs to set up a bulletin board system on a NEC APC.
It can be either CP/M-86 or MS-DOS.  Since it's extremely unlikely that
one exists already configured for the APC, it probably has to include at
a minimum the ability to link in or overlay the communications routines.
Can anyone give me pointers?

-- Ron
-------
 1-Oct-85 08:02:32-MDT,658;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 1 Oct 85 08:02:27-MDT
Received: from mit-multics.arpa by AMSAA.ARPA id a022497; 1 Oct 85 9:31 EDT
Date:  Tue, 1 Oct 85 09:30 EDT
From:  AALevy@MIT-MULTICS.ARPA
Subject:  program to help WSTAR find overlays
To:  info-cpm@AMSAA.ARPA
Message-ID:  <851001133017.582675@MIT-MULTICS.ARPA>

There is a program that modified WSTAR and similar programs to find
overlays even if they were on another disk or user area.  I believe it
was called SETDRU (I could be wrong).  I do not know if it was PD or
not.  Any help would be appreciated.

Regards,

Allan
 1-Oct-85 10:18:45-MDT,1025;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 1 Oct 85 10:18:39-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a026279; 1 Oct 85 11:35 EDT
Received: from csnet-pdn-gw by AOS.BRL.ARPA id a016103; 1 Oct 85 10:20 EDT
Received: from gmr by csnet-relay.csnet id ad01709; 1 Oct 85 10:17 EDT
Date:     Tue, 1 Oct 85 08:22 EST
From:      haar%gmr.csnet@CSNET-RELAY.ARPA
MMDF-Warning:  Parse error in original version of preceding line at CSNET-RELAY.ARPA
To:       info-cpm@BRL.ARPA
Subject:  D.R.C. S-100 RamDisk

Have any of you used the 256K S-100 Solid State Disk Simulator (ramdisk)
from Digital Research Computers ? If so, I would like to hear your comments.
I am thinking about getting one since the price has dropped to less than $200.

They provide BIOS code for CP/M 2.2. Does anyone have a CP/M Plus version?
Is it really S-100 (IEEE 696) compatible? Is it reliable?

I would appreciate any advice on this product/company.

thanks,

      Bob Haar
 1-Oct-85 11:12:57-MDT,1138;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 1 Oct 85 11:12:50-MDT
Received: from rand-unix.arpa by AMSAA.ARPA id a028074; 1 Oct 85 12:39 EDT
Return-Path: <bridger@rand-unix.ARPA>
Received: by rand-unix.ARPA; Tue, 1 Oct 85 09:44:16 pdt
From: Bridger Mitchell <bridger@RAND-UNIX.ARPA>
Message-Id: <8510011644.AA14995@rand-unix.ARPA>
Date: 01 Oct 85 09:44:14 PDT (Tue)
To: AALevy@MIT-MULTICS.ARPA
Cc: info-cpm@AMSAA.ARPA, bridger@RAND-UNIX.ARPA
Subject: Re: program to help WSTAR find overlays
In-Reply-To: Your message of Tue, 1 Oct 85 09:30 EDT.
	     <851001133017.582675@MIT-MULTICS.ARPA>

SETDRU is one method.  PUBlic files are another, one
that requires no patches to the program and uses no tpa,
but does patch the bdos. 

PUBPATCH, in the simtel20 directory of that name, is a z80
patch to an UNMODIFIED cp/m 2.2  bdos that makes a file
PUBlic when attrribute bit 2 is set in the directory.
A PUBlic file is accessible from all user numbers on
the disk.  See  our article in Dr. Dobbs' Jrnl. Oct (or Nov) 1984
for further description.

--bridger mitchell
 1-Oct-85 11:25:16-MDT,1126;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 1 Oct 85 11:25:11-MDT
Received: from apg-1.arpa by AMSAA.ARPA id a028506; 1 Oct 85 12:53 EDT
Date: Tue, 1 Oct 85 12:46:23 EDT
From: Robert Bloom AMSTE-TOI 3775 <rbloom@apg-1.ARPA>
Subject: Re: program to help WSTAR find overlays
In-Reply-To: Your message of Tue, 1 Oct 85 09:30 EDT
To: AALevy@MIT-MULTICS.ARPA
Cc: info-cpm@AMSAA.ARPA

<cpm.dirutl>setdru.lbr is the file name of the program you asked for 
to let WordStar find its overlays files in other user areas.

However, I don't think that is what you *really* want.  For that,
look to <cpm.pubpatch>pubpat.lbr.  That is a BDOS patch that allows
*any* program to cross user lines for overlays. (I use it for
WordStar, dBase and SuperCalc with no problems.)

One activatives a file to be accessable in any area by setting the
high-bit of second character of the file-name.  I use NSWP for this,
the pubpat libarary has it's own program for it.  There are some
side effects but none as bad as those in setdru.  As Jerry says,
recommended.

-bob bloom

 1-Oct-85 13:13:36-MDT,7758;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 1 Oct 85 13:13:20-MDT
Date:     Tue, 1 Oct 85 14:14:36 EDT
From:     David Towson (SECAD) <towson@AMSAA.ARPA>
To:       info-cpm@AMSAA.ARPA
Subject:  7000+ character tutorial on sending BREAK:

Fellow CP/Mers - In response to a recent request for information regarding
how to send BREAK from a microcomputer, here is a 7000+ character tutorial on
the subject.  Sample code is included.

     The American Standard Code for Information Interchange (ASCII) defines a
set of 128 characters that are encoded as the various combinations of seven
bits.  When this code is used over a serial asynchronous communications link,
some additional bits are added to the seven ASCII bits to form the total
"package" that is transmitted for each character sent.

     The term "asynchronous" means that the receiver doesn't know in advance
when a character is coming.  It just sits in an "idle" state until some special
event signals the start of a new character.  This idle state is caused by the
presence of a steady logic-one signal at the receiver input, and it can last
indefinitely.  The "special event" that signals the beginning of a new
character is a transition from the idle-state logic-one signal to a logic-zero
which lasts for one bit-time, and is known as a "start-bit".

     A start-bit "wakes-up" the receiver, which then records in some sort of
memory, typically a shift-register, the states of the next seven or eight bits.
Whether seven or eight bits are recorded depends on whether "parity" is being
used.  Parity is a simple error detection scheme that, though easily deceived,
is better than nothing.  It is implemented by adding an extra bit (the eighth
bit) to the existing seven ASCII bits such that the total number of logic-one
bits in the eight-bit group is either odd or even, depending on whether "odd
parity" or "even parity" is being used.  For example, the ASCII representation
for "A" is "1000001", which has an even number of 1's.  Therefore, adding even
parity results in "01000001", which still has an even number of 1's, whereas
the odd parity representation is "11000001".

     After the start-bit and seven or eight "data-bits", the receiver expects
to see a return to the logic-one state to signify the end of the character.
This logic-one state lasts for at least one bit-time, and is known as a
"stop-bit" (or bits).  Typically, one stop-bit is used for all speeds greater
than 110 baud, and two stop-bits are used at 110 baud and below.  This
convention derives from the mechanical roots of teleprinting, where the
electro-mechanical devices used to decode and print the received characters
needed time to stop quivering after each character before being ready to decode
and print the next.

     To summarize then, an ASCII character sent via an asynchronous serial
channel consists of one start-bit, seven or eight data-bits (depending on
whether parity is being used), and one or two stop-bits (depending on the
speed of transmission).  This brings us (at last) to the BREAK signal.

     The BREAK signal has its roots at least as far back as the days of
mechanical teleprinters, perhaps all the way back to electro-mechanical
telegraphy.  Early teleprinters used an electro-mechanical device called a
"selector" to perform the decoding function now done electronically by devices
such as the Universal Asynchronous Receiver Transmitter (UART).  The start-bit
caused a current flowing in the selector electro-magnet to cease, thereby
releasing a clutch that set into motion a complex mechanical process that
resulted in the printing of the received character.  This process made a
considerable noise, even when a non-printing character such as a space was
received.  If a steady logic-zero signal (no current in the selector magnet)
was presented to the receiving teleprinter, the machine emitted a steady
rhythmic clunking that was impossible to ignore.  Consequently, the machines
had a key labeled BREAK that merely opened the series DC circuit connecting
all transmitters and receivers in the teleprinter network, thereby getting the
attention of all operators.  There was also a BELL character, but this had to
be correctly decoded by a receiver in order to ring the bell, whereas the
BREAK was a "non-character" that could be used to interrupt a transmission-
in-progress, since it simply disrupted the whole network and made a lot of
noise at each receiving teleprinter.

     Today, the BREAK signal performs a similar function in a similar manner.
It is used now most often to gain the attention of a computer or other
machine, rather than to alert a human operator.  But it is still generated by
sending a logic-zero signal of indeterminate length, although by convention
some specific durations (typically in the 300 - 500 millisecond range) have
been adopted.  Modern electronic receiving circuits such as those whose names
end with "ART" (as in UART) interpret the beginning of the BREAK as a start-bit
followed by seven or eight logic-zero data-bits (the ASCII NUL character).  But
the expected stop-bit (return to logic-one state) is missing.  This causes the
receiving circuit to generate an error condition called "framing error", which
is typically signaled by the setting of an error-bit in the status register
of the receiving device.  How the "user machine" responds to this condition is
determined by the user-machine's software.

     The example to follow shows how a BREAK can be sent via software control
of a 1602 UART.  This device, which is typical of many such devices, has a
command instruction that forces the output to a logic-zero state until the
complementary instruction is issued.  The code is taken from my MODEM7 overlay
for the TRS-80 Model-I computer.  All code not needed for this specific
example has been deleted.

;.....
;
RESETP:		EQU	0E8H	;Reset port for UART.
BAUDP:		EQU	0E9H	;Data-rate port for UART.
CONTROLP:	EQU	0EAH	;Status/control port for UART.
BRKMASK:	EQU	0FBH	;And-mask to turn on break.
;
;.....
;
;
; UART initialization routine for TRS-80 Model I.
;
TRSINIT:	OUT	RESETP		;Reset UART (data in A register is
					;insignificant).
		MVI	A,55H		;Use 55H for 300 baud.
					;Use 77H for 1200 baud.
		OUT	BAUDP		;Set UART data-rate.
;
		MVI	A,0ECH		;Set UART for 8-bit word,
					;no parity, no break and
		OUT	CONTROLP	;DTR and RTS on.
		STA	CONTROLB	;Save the UART control byte.
		RET			;
;
;
;.....
;
;
CONTROLB:	DB	0		;UART control byte save.
;
;
;.....
;
;
; Routine to send a break-tone of approximately 300 ms duration.
;
SENDBRK:	PUSH	B		;Save all double registers.
		PUSH	D		;
		PUSH	H		;
		LDA	CONTROLB	;Get current UART control byte.
		ANI	BRKMASK		;Change bit to turn on break.		
		OUT	CONTROLP	;Send new byte to control port.
		MVI	B,3		;Set count for timer.
		CALL	TIMER		;Wait 300 milliseconds.		
		LDA	CONTROLB	;Restore original control byte		
		OUT	CONTROLP	;to turn off break.
		POP	H		;Restore double registers.
		POP	D		;
		POP	B		;
		RET			;
;
;
;.....


Note that the particular control-bytes needed to program the 1602 UART were
determined from the 1602 data sheet.  It is pointless to attempt writing this
kind of code unless you have access to this kind of information.  Many readers
of info-cpm can help in this regard.

     Many other examples can be found in the overlay files on SIMTEL20 in
directories PD:<CPM.MODEM7> and PD:<CPM.MEX>, available via FTP with login
username "anonymous" and password "ftp" (or any other printing string).



						Dave
						<towson@amsaa.arpa>

 1-Oct-85 13:34:12-MDT,2747;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 1 Oct 85 13:34:03-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a002463; 1 Oct 85 14:50 EDT
Received: from mit-mc.arpa by AOS.BRL.ARPA id a025834; 1 Oct 85 14:32 EDT
Received: from CSNET-RELAY.ARPA by MIT-MC.ARPA  1 Oct 85 14:32:53 EDT
Received: from gte-labs by csnet-relay.csnet id ab03440; 1 Oct 85 14:23 EDT
Received: by bunny.UUCP (4.12/5.03) id AA19995; Tue, 1 Oct 85 10:37:14 edt
	for 
Date: Tue, 1 Oct 85 10:37:14 edt
From: Alan Gunderson <asg0%gte-labs.csnet@CSNET-RELAY.ARPA>
To: info-cpm%mit-mc.csnet@BRL.ARPA
Subject: SB180 help


I have purchased a SB180 board and have wired it into a power supply
and installed two Tandon TM-65-2 48 tpi 5-1/4" DSDD drives (80 tracks
per drive, unformatted 500K bytes maximum storage).  These
drives do not support the READY line, so I have installed the JP 6
jumper on the SB180, which makes the disk controller think the disk
drives are always ready.  The ROM monitor on the SB180, when it see's
that the drives are ready, assumes that the user wants to autoboot from
the floppy.  When I try to boot the ZRDOS operating system, I get
the operating system sign-on for version 2.1 of ZRDOS.
According to the manual, this indicates that ZRDOS has
been correctly loaded into memory.  I then get the message

     Read Error on A:

     I have installed a switch as part of my JP 6 jumper, so I can make
the monitor think that the floppies are not ready and thus enter the
command entry state.  From the monitor, I have not been able to format
floppies.  The program disappears for a time and then aborts with a
dump of the disk controller status registers and the head, track, and
sector in which the format dies.  Using the monitor R command, I am
able to read sectors from the operating system diskette.  When I go
beyond sector 9 with the read, I get the same disk controller status
register dump.

     The Tandon drives do not support the Head Load line in the
interface.  This is pin 4 and is listed as a spare for the floppy.
The SB180 manual alludes to the fact that Head Load is not required
but is desirable to extend the life of the diskettes.  Is this line
required?  Is there any way to make the Tandon drives support the
READY line (pin 34)?  The Tandon manual alludes to this line being
optionally enabled, but does not tell how.  There is no jumper
documented.

     Has anyone else tried to interface this type of drive to the
SB180?  If so, please provide any hints or insights.  Any other SB180
ideas??

Thanks in advance.

====Alan Gunderson
uucp:  ...!seismo!harvard!bunny!asg0
csnet: asg0%gte-labs.csnet@csnet-relay.arpa


 2-Oct-85 06:41:19-MDT,1896;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 2 Oct 85 06:41:11-MDT
Received: from usc-isid.arpa by AMSAA.ARPA id a004267; 2 Oct 85 7:34 EDT
Date: 2 Oct 1985 06:30-EDT
Sender: ABN.ISCAMS@USC-ISID.ARPA
Subject: Re: program to help WSTAR find overlays
From: ABN.ISCAMS@USC-ISID.ARPA
To: bridger@RAND-UNIX.ARPA
Cc: AALevy@MIT-MULTICS.ARPA, info-cpm@AMSAA.ARPA
Message-ID: <[USC-ISID.ARPA] 2-Oct-85 06:30:37.ABN.ISCAMS>
In-Reply-To: <8510011644.AA14995@rand-unix.ARPA>

Re PUBPATCH in finding WS overlays..

PUBPATCH will look to "root" disk same user, then "root" disk user 0, for
.COM files but will NOT find overlays!  (Had this problem with WS,
Turbo Pascal, others.)  Also, while within WS, you can't RUN programs
not in your immediate user area because WS doesn't seem to use the BDOS
calls to find files.  So PUBPATCH won't be of much help in this case.

I ended up keeping one copy of WS.COM in my "root" disk, A0, along with
"original" copies of the required overlays.  Then used DUPUSR (another
public domain program .. copies a directory entry to another user area
but NOT the program, saving MUCH disk space) to copy overlay file names
to all required user areas.  STATed them protected and invisible so the
names wouldn't be in the way.  Could then run WS from any disk any user,
with NO increased disk usage.

Worked fine, did the same with Turbo Pascal and a couple other programs
that had associated data files.

Yep, there is a WS patch program in the SIMTEL20 archives, and I think
it IS named SETDRU.COM.  Patches WS directly, as I recall, so WS is then smart
enough to find its overlays at a selected "root" disk/user.  A little more
elegant than my DUPUSR kludge, but then I'd used DUPUSR for other things
and kind of got in a rut.

Regards,
David Kirschbaum
Toad Hall
ABN.ISCAMS@USC-ISID
 2-Oct-85 07:09:21-MDT,844;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 2 Oct 85 07:09:16-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a003341; 2 Oct 85 7:10 EDT
Received: from simtel20.arpa by AOS.BRL.ARPA id a001682; 2 Oct 85 1:36 EDT
Date: Monday, 30 September 1985  13:50-MDT
Message-ID: <KPETERSEN.12147813866.BABYL@SIMTEL20.ARPA>
Sender: "B.Eiben LCG Ext 617-467-4431" <EIBEN@DEC-MARLBORO.ARPA>
From: "B.Eiben LCG Ext 617-467-4431" <EIBEN@DEC-MARLBORO.ARPA>
Subject:   CPM:Floppy.fmt
ReSent-From: KPETERSEN@SIMTEL20.ARPA
ReSent-To: Info-Cpm@BRL.ARPA
ReSent-Date: Tue 1 Oct 1985 23:34-MDT

Filename			Type	 Bytes	 CRC

SIMTEL20 directory MICRO:<CPM.GENDOC>
FLOPPY.FMT.5			ASCII	 10708  7BDDH

Has been updated [thanks to Hal Bower] with AMPRO-info - and some
entries have been corrected too.
 2-Oct-85 07:11:18-MDT,1230;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 2 Oct 85 07:11:12-MDT
Received: from lll-mfe.arpa by AMSAA.ARPA id a003458; 2 Oct 85 7:14 EDT
Date: Tue, 1 Oct 85 16:49 EDT
From: SECRIST%OAK.SAINET.MFENET@LLL-MFE.ARPA
Subject: CCPPATCH.ASM
To: INFO-CPM@AMSAA.ARPA




There is some code on [the fine] Royal Oak BBS (ergo SIMTEL20) called
CCPPATCH.ASM.  It's purpose in life is similar to that of the Wordstar
user-number hoppers that have been discussed of late, only it's more
generic - instead of user numbers it works with drives.  For example,
if I try to fire up an image on C: and it's not there, CCPPATCH makes
the system look on A: before it errors-out on you.

My problem is - what do you build it with and/or does it work ?  I
blindly threw it at ASM, but ASM wasn't fond of it - undefined labels.
I dunno - maybe those are Z80 ops.  Basically, I want a tool to do this
intended purpose, and if you have had luck with CCPPATCH and can correct
my brain damage or have a similar tool, I'll be happy to summarize the
responses to the net.

Richard Secrist
Science Applications Int'l. Corp., Oak Ridge, Tenn.

SECRIST%OAK.SAInet.MFEnet@LLL-MFE.Arpa
 2-Oct-85 07:15:28-MDT,659;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 2 Oct 85 07:15:22-MDT
Received: from css-ring-gw by AMSAA.ARPA id a003824; 2 Oct 85 7:23 EDT
Return-Path: <wucs!sbc>
Received: from wucs.UUCP by seismo.CSS.GOV with UUCP; Tue, 1 Oct 85 21:21:09 EDT
Received: by wucs.WU.UUCP; Tue, 1 Oct 85 19:36:05 CDT
Date: Tue, 1 Oct 85 19:36:05 CDT
From: Steve Cousins <wucs!sbc@seismo.seismo.ARPA>
Message-Id: <8510020036.AA22977@wucs.WU.UUCP>
To: info-cpm@AMSAA.ARPA, info-cpm-request@AMSAA.ARPA
Subject: Please remove me from the info-cpm list


Please take my name off of the list.

Thanks.

Steve Cousins
 2-Oct-85 07:19:08-MDT,1631;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 2 Oct 85 07:19:00-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id aa04022; 2 Oct 85 7:27 EDT
Received: from usenet by TGR.BRL.ARPA id a007076; 1 Oct 85 16:20 EDT
From: Chuck McManis <cem%intelca.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: Little Board / SB180 compatibility
Message-ID: <104@intelca.UUCP>
Date: 30 Sep 85 15:40:34 GMT
To:       info-cpm@AMSAA.ARPA

> For AMPRO/Little Board and Ciarcia HD64180 board owners.
> An undocumented feature that I discovered is that the
> 5 1/4 disc formats are identical for both machines.
> 
> Now what engineer in his right mind would have made that
> unforgivable error?  Must be a bug...
> -------

Hardly undocumented, since it says so right in the article. Yet why consider
it a bug? Are we missing a smiley face here? So now that I have built my 
new system into a Fraggle Rock lunch box where do I put my sandwich? 
Kaypro eat your heart out.      \\
                           ::    \\
                           ::     ||
                                  || (a poor attempt at a LARGE smiley face)
                           ::     ||
                           ::    // 
                                //     
--Chuck
-- 
                                            - - - D I S C L A I M E R - - - 
{ihnp4,fortune}!dual\                     All opinions expressed herein are my
        {qantel,idi}-> !intelca!cem       own and not those of my employer, my
 {ucbvax,hao}!hplabs/                     friends, or my avocado plant. :-}
 2-Oct-85 07:38:09-MDT,898;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 2 Oct 85 07:38:04-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a006240; 2 Oct 85 8:25 EDT
Received: from simtel20.arpa by AOS.BRL.ARPA id a004470; 2 Oct 85 8:15 EDT
Date: Monday, 30 September 1985  22:56-MDT
Message-ID: <KPETERSEN.12147886389.BABYL@SIMTEL20.ARPA>
Sender: David Roth <ihnp4!inuxc!isrnix!pugsly@UCB-VAX.ARPA>
From: David Roth <ihnp4!inuxc!isrnix!pugsly@UCB-VAX.ARPA>
To: w8sdz@SIMTEL20.ARPA
Subject:   Converting 8080/z80 to 'C'?
ReSent-From: KPETERSEN@SIMTEL20.ARPA
ReSent-To: Info-Cpm@BRL.ARPA
ReSent-Date: Wed 2 Oct 1985 06:12-MDT

Is there any easy way to convert 8080/Z80 asm. language to 'C'?
Like some kind of translator or something?
(I have a feeling I am wishing!)
Thanks in advance.
			David A. Roth
		...decvax!pur-ee!isrnix!pugsly
			Indianapolis,IN
 2-Oct-85 07:44:26-MDT,780;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 2 Oct 85 07:44:19-MDT
Received: from usc-eclb.arpa by AMSAA.ARPA id a006924; 2 Oct 85 8:41 EDT
Date: 2 Oct 1985 05:42-PDT
Sender: STANLEY@USC-ECLB.ARPA
Subject: Compiler Patches
From: STANLEY@USC-ECLB.ARPA
To: info-cpm@AMSAA.ARPA
Message-ID: <[USC-ECLB.ARPA] 2-Oct-85 05:42:32.STANLEY>

I seem to remember reading about a short patch that enabled one
to buy compoilers (such as FORTRAN & COBOL) written for the Heath
89/90 and run them on things like the Osborne, thus saving money
since the Zenith product was cheaper.  Trouble is, I can't find
the original article.  Anyone have any ideas or remembrances?

Thanks.

                                ...Dick Stanley
 2-Oct-85 08:13:44-MDT,1004;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 2 Oct 85 08:13:33-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a007081; 2 Oct 85 8:43 EDT
Received: from xerox.arpa by AOS.BRL.ARPA id a005138; 2 Oct 85 8:38 EDT
Received: from Muscat.ms by ArpaGateway.ms ; 02 OCT 85 05:35:08 PDT
Date: Wed, 2 Oct 85 08:00 EDT
From: Kushall.henr@XEROX.ARPA
Subject: Re: D.R.C. S-100 RamDisk
In-reply-to: "haar@gmr.CSNet.AG's message of Tue, 1 Oct 85 08:22 EST"
To: haar%gmr.CSNet@CSNET-RELAY.ARPA
cc: info-cpm@BRL.ARPA
Message-ID: <851002-053508-1280@Xerox>

I haven't used there RAM disk board, but have used other boards from
them S-100 static RAM and ROM boards all with no problems, these boards
seemed well designed and the PWB was of good quality. The instructions
were good(I built mine from the bare boards)

PS: Digital Research Computers brought out a single board computer
called "Big Board", Xerox later based the 820 on this design.
ED

 2-Oct-85 09:24:06-MDT,8338;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 2 Oct 85 09:23:49-MDT
Received: from xerox.arpa by AMSAA.ARPA id a010863; 2 Oct 85 10:39 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 02 OCT 85 07:42:36 PDT
Sender: "Leonard A. Raye.EIS"@XEROX.ARPA
Date: 2 Oct 85 07:40:00 PDT (Wednesday)
Subject: 7000+ character tutorial on sending BREAK:
From: towson@AMSAA.ARPA
To: info-cpm@AMSAA.ARPA
Message-ID: <851002-074236-1350@Xerox>

GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV
From: David Towson (SECAD) <towson@AMSAA.ARPA>
To: info-cpm@AMSAA.ARPA
Subject: 7000+ character tutorial on sending BREAK:
Return-Path: <info-cpm-request@AMSAA.ARPA>
Redistributed: XeroxInfo-CPM^.wbst
Received: from AMSAA (AMSAA.ARPA) by Xerox.ARPA ; 01 OCT 85 12:31:46 PDT
GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV

Fellow CP/Mers - In response to a recent request for information regarding
how to send BREAK from a microcomputer, here is a 7000+ character tutorial on
the subject.  Sample code is included.

     The American Standard Code for Information Interchange (ASCII) defines a
set of 128 characters that are encoded as the various combinations of seven
bits.  When this code is used over a serial asynchronous communications link,
some additional bits are added to the seven ASCII bits to form the total
"package" that is transmitted for each character sent.

     The term "asynchronous" means that the receiver doesn't know in advance
when a character is coming.  It just sits in an "idle" state until some special
event signals the start of a new character.  This idle state is caused by the
presence of a steady logic-one signal at the receiver input, and it can last
indefinitely.  The "special event" that signals the beginning of a new
character is a transition from the idle-state logic-one signal to a logic-zero
which lasts for one bit-time, and is known as a "start-bit".

     A start-bit "wakes-up" the receiver, which then records in some sort of
memory, typically a shift-register, the states of the next seven or eight bits.
Whether seven or eight bits are recorded depends on whether "parity" is being
used.  Parity is a simple error detection scheme that, though easily deceived,
is better than nothing.  It is implemented by adding an extra bit (the eighth
bit) to the existing seven ASCII bits such that the total number of logic-one
bits in the eight-bit group is either odd or even, depending on whether "odd
parity" or "even parity" is being used.  For example, the ASCII representation
for "A" is "1000001", which has an even number of 1's.  Therefore, adding even
parity results in "01000001", which still has an even number of 1's, whereas
the odd parity representation is "11000001".

     After the start-bit and seven or eight "data-bits", the receiver expects
to see a return to the logic-one state to signify the end of the character.
This logic-one state lasts for at least one bit-time, and is known as a
"stop-bit" (or bits).  Typically, one stop-bit is used for all speeds greater
than 110 baud, and two stop-bits are used at 110 baud and below.  This
convention derives from the mechanical roots of teleprinting, where the
electro-mechanical devices used to decode and print the received characters
needed time to stop quivering after each character before being ready to decode
and print the next.

     To summarize then, an ASCII character sent via an asynchronous serial
channel consists of one start-bit, seven or eight data-bits (depending on
whether parity is being used), and one or two stop-bits (depending on the
speed of transmission).  This brings us (at last) to the BREAK signal.

     The BREAK signal has its roots at least as far back as the days of
mechanical teleprinters, perhaps all the way back to electro-mechanical
telegraphy.  Early teleprinters used an electro-mechanical device called a
"selector" to perform the decoding function now done electronically by devices
such as the Universal Asynchronous Receiver Transmitter (UART).  The start-bit
caused a current flowing in the selector electro-magnet to cease, thereby
releasing a clutch that set into motion a complex mechanical process that
resulted in the printing of the received character.  This process made a
considerable noise, even when a non-printing character such as a space was
received.  If a steady logic-zero signal (no current in the selector magnet)
was presented to the receiving teleprinter, the machine emitted a steady
rhythmic clunking that was impossible to ignore.  Consequently, the machines
had a key labeled BREAK that merely opened the series DC circuit connecting
all transmitters and receivers in the teleprinter network, thereby getting the
attention of all operators.  There was also a BELL character, but this had to
be correctly decoded by a receiver in order to ring the bell, whereas the
BREAK was a "non-character" that could be used to interrupt a transmission-
in-progress, since it simply disrupted the whole network and made a lot of
noise at each receiving teleprinter.

     Today, the BREAK signal performs a similar function in a similar manner.
It is used now most often to gain the attention of a computer or other
machine, rather than to alert a human operator.  But it is still generated by
sending a logic-zero signal of indeterminate length, although by convention
some specific durations (typically in the 300 - 500 millisecond range) have
been adopted.  Modern electronic receiving circuits such as those whose names
end with "ART" (as in UART) interpret the beginning of the BREAK as a start-bit
followed by seven or eight logic-zero data-bits (the ASCII NUL character).  But
the expected stop-bit (return to logic-one state) is missing.  This causes the
receiving circuit to generate an error condition called "framing error", which
is typically signaled by the setting of an error-bit in the status register
of the receiving device.  How the "user machine" responds to this condition is
determined by the user-machine's software.

     The example to follow shows how a BREAK can be sent via software control
of a 1602 UART.  This device, which is typical of many such devices, has a
command instruction that forces the output to a logic-zero state until the
complementary instruction is issued.  The code is taken from my MODEM7 overlay
for the TRS-80 Model-I computer.  All code not needed for this specific
example has been deleted.

;.....
;
RESETP:		EQU	0E8H	;Reset port for UART.
BAUDP:		EQU	0E9H	;Data-rate port for UART.
CONTROLP:	EQU	0EAH	;Status/control port for UART.
BRKMASK:	EQU	0FBH	;And-mask to turn on break.
;
;.....
;
;
; UART initialization routine for TRS-80 Model I.
;
TRSINIT:	OUT	RESETP		;Reset UART (data in A register is
					;insignificant).
		MVI	A,55H		;Use 55H for 300 baud.
					;Use 77H for 1200 baud.
		OUT	BAUDP		;Set UART data-rate.
;
		MVI	A,0ECH		;Set UART for 8-bit word,
					;no parity, no break and
		OUT	CONTROLP	;DTR and RTS on.
		STA	CONTROLB	;Save the UART control byte.
		RET			;
;
;
;.....
;
;
CONTROLB:	DB	0		;UART control byte save.
;
;
;.....
;
;
; Routine to send a break-tone of approximately 300 ms duration.
;
SENDBRK:	PUSH	B		;Save all double registers.
		PUSH	D		;
		PUSH	H		;
		LDA	CONTROLB	;Get current UART control byte.
		ANI	BRKMASK		;Change bit to turn on break.		
		OUT	CONTROLP	;Send new byte to control port.
		MVI	B,3		;Set count for timer.
		CALL	TIMER		;Wait 300 milliseconds.		
		LDA	CONTROLB	;Restore original control byte		
		OUT	CONTROLP	;to turn off break.
		POP	H		;Restore double registers.
		POP	D		;
		POP	B		;
		RET			;
;
;
;.....


Note that the particular control-bytes needed to program the 1602 UART were
determined from the 1602 data sheet.  It is pointless to attempt writing this
kind of code unless you have access to this kind of information.  Many readers
of info-cpm can help in this regard.

     Many other examples can be found in the overlay files on SIMTEL20 in
directories PD:<CPM.MODEM7> and PD:<CPM.MEX>, available via FTP with login
username "anonymous" and password "ftp" (or any other printing string).



						Dave
						<towson@amsaa.arpa>

 2-Oct-85 11:40:27-MDT,1193;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 2 Oct 85 11:40:11-MDT
Received: from apg-1.arpa by AMSAA.ARPA id a015354; 2 Oct 85 13:09 EDT
Date: Wed, 2 Oct 85 12:58:05 EDT
From: Robert Bloom AMSTE-TOI 3775 <rbloom@apg-1.ARPA>
Subject: Re: program to help WSTAR find overlays
In-Reply-To: Your message of 2 Oct 1985 06:30-EDT
To: ABN.ISCAMS@USC-ISID.ARPA
Cc: info-cpm@AMSAA.ARPA

David,
Maybe your BDOS is not standard ....

i.e. I do exactly what you say doesn't work - I have WS.COM, WSOVLY.COM and
WSMSGS.ORVR in user 0 disk A.  Now, any disk, any user can type 'WS' and
expect to get WordStar (running the ZCPR2 patches also.)  The 'r' command
of WordStar doesn't work as you stated unless the target program is also
marked public.  Note that the WS internal search for overlay must have
the proper drive where the overlays are located (label DEFDSK)

I used to use the DUPUSR kludge but got burned by it from (my) carelessness.
pubpatch is more 'elegant'.

(All of this on a NorthStar Horizon w/352k running TSS/C, a multi-user
CP/M system using one Z80 and bankswitching.  [yes, it *is* slow at times!])

-bob

 3-Oct-85 06:48:54-MDT,1747;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 3 Oct 85 06:48:45-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a023637; 3 Oct 85 7:56 EDT
Received: from usenet by TGR.BRL.ARPA id a011597; 3 Oct 85 6:42 EDT
From: Eric Hestenes <hestenes%sdcsla.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: Classified ads
Message-ID: <991@sdcsla.UUCP>
Date: 29 Sep 85 20:43:52 GMT
To:       info-cpm@AMSAA.ARPA

> REF: Msg by Jack H. Smith on classified ads in mail.

What exactly is an unwanted ad?

Is it a For Sale ad, or is it a request for the latest version of MODEM ?
Is it and ad that implies exchange of cash, or exchange of floppies?

Is this group therefore just for technical info, and not a place to
connect with other users?

It seems silly to forbid most ads for personal entities ( not commmercial 
entities ) because they mostly involve give and take between legitimately
interested parties. The primary assumption of the "personal" ad here is that
the ad will be used on one occasion, e.g. to get rid of your cpm system.
Abuses therefore include only those people who try to get rid of more than
a few of an item ( "I've got 300,000 cpm systems to get rid of and a special
rate for net people" ).  

the whole point of using the net is that it allows you to interact with people
with a common interest. If you take out the common interest variable by
placing the ad in a general-purpose mailing group, then you defeat this
purpose. 

Ads that did not relate to cpm *would* be objectionable.

eric

[ these views are my own, not the views of my employer. ]
arpanet: hestenes@nprdc.ARPA
other: ucbvax!sdcsvax!sdcsla!hestenes or hestenes@sdcsla.UUCP
 3-Oct-85 07:00:32-MDT,1362;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 3 Oct 85 07:00:26-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a023876; 3 Oct 85 8:03 EDT
Received: from usenet by TGR.BRL.ARPA id a012915; 3 Oct 85 7:46 EDT
From: amc543%uiucuxa.uiuc.arpa@BRL.ARPA
Newsgroups: net.micro.cpm
Subject: Two CP/M Computers for Sale
Message-ID: <10100001@uiucuxa>
Date: 27 Sep 85 16:43:00 GMT
Nf-ID: #N:uiucuxa:10100001:000:788
Nf-From: uiucuxa.Uiuc.ARPA!amc543    Sep 27 11:43:00 1985
To:       info-cpm@AMSAA.ARPA


I have the following two computers for sale:

1) Kaypro 2X transportable 64k CP/M computer.   9" hi-res green monitor,
two 5.25" floppy drives holding 390k each, excellent Selectric keyboard,
WordStar, MailMerge, MBASIC, spreadsheets, and lots and lots of public
domain software.  The whole machine is one suitcase-like carryable
package, like a Compaq.  Includes 2 serial ports, 1 parallel port.
Asking $900 or offer.

2) Epson Geneva battery-powered laptop computer with separate battery-
powered 3.5" floppy drive included.  64k CP/M system with 80 x 8 display,
runs all the regular CP/M software including Turbo Pascal and dBASE II.
Includes WordStar, Portable Calc, Portable Scheduler, BASIC, more.
Fantastic portable word processing system.  $700.

Aaron Contorer, (217) 332-4226.
 3-Oct-85 08:39:52-MDT,1934;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 3 Oct 85 08:39:43-MDT
Received: from mitre.arpa by AMSAA.ARPA id a026992; 3 Oct 85 10:01 EDT
Received: by mitre.ARPA (4.12/4.7)
	id AA12747; Thu, 3 Oct 85 10:05:27 edt
Message-Id: <8510031405.AA12747@mitre.ARPA>
To: Eric Hestenes <hestenes%sdcsla.uucp@BRL.ARPA>
Cc: info-cpm@AMSAA.ARPA
Subject: Re: Classified ads
In-Reply-To: Your message of 29 Sep 85 20:43:52 GMT.
	     <991@sdcsla.UUCP>
Date: 03 Oct 85 10:03:04 EDT (Thu)
From: Jeff Edelheit <edelheit@MITRE.ARPA>

Eric - Since I started the discussion, I'd like to reply to your comments.

There were several reasons for the establishment of the ARPANET.  First, and
foremost, was to develop the concept of packet switching.  Once you could do
that, it seemed that a logical use was to foster communications of technical
issues between interested parties.  Requests for help in bringing-up the 
latest version of a package (proprietary or public domain) is valid.  Comments
on the use of a proprietary object (software, hardware) are valid, as well, in
my opinion, the experiences had with a commercial vendor (I have had a bad 
experience with XYZ, Inc).  All of these topics allow for the passing of 
information between interested parties.  I, for one, would like to know that
if you buy a product from XYZ for either employment/research or 
personal-related work, the kind of support you might get from the vendor.

The ARPANET was not intended for use as an advertising medium for either
commercial concerns or individuals to sell goods and/or services.  

My comments are based on the idea that ARPANET is a DoD-funded activity, not
funded and supported by the private sector.  The above comments are strictly
personal and do not reflect those of either my employer, DoD or any other
government agency.

Jeff Edelheit
(edelheit@mitre.arpa)
 3-Oct-85 11:50:23-MDT,666;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 3 Oct 85 11:50:18-MDT
Received: from su-sushi.arpa by AMSAA.ARPA id a001030; 3 Oct 85 13:05 EDT
Date: Thu 3 Oct 85 10:04:33-PDT
From: Sam Hahn <Samuel@SU-SUSHI.ARPA>
Subject: Re: Two CP/M Computers for Sale
To: amc543%uiucuxa.uiuc.arpa@BRL.ARPA
cc: info-cpm@AMSAA.ARPA
In-Reply-To: Message from "amc543%uiucuxa.uiuc.arpa@BRL.ARPA" of Fri 27 Sep 85 16:43:00-PDT

I may be interested in the Epson laptop.
How can I find out about this machine, before I make a bid?

					-- Sam Hahn

[Tried sending this directly, but got a "host unknown" message]
-------
 3-Oct-85 13:03:56-MDT,1058;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 3 Oct 85 13:03:50-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a003845; 3 Oct 85 14:25 EDT
Received: from usenet by TGR.BRL.ARPA id a026000; 3 Oct 85 14:09 EDT
From: David Roth <pugsly%isrnix.uucp@BRL.ARPA>
Newsgroups: net.micro.cbm,net.micro.cpm,net.wanted
Subject: Wanted: Screen editor for CP/M on the C64.
Message-ID: <575@isrnix.UUCP>
Date: 30 Sep 85 16:17:58 GMT
Xref: seismo net.micro.cbm:1810 net.micro.cpm:5058 net.wanted:7787
To:       info-cpm@AMSAA.ARPA

I have the CP/M option for my C64. I have used many CP/M systems in the past and
have been spoiled by the use of screen
editors. Does anyone know if any exists
for the C64's CP/M option? ED is about to
drive me up a wall. Anyone got WordStar working on it...like the WS for the
apple using the Z80 card?
Please reply by mail.
Thanks in advance.
                        David A. Roth
                ...decvax!pur-ee!isrnix!pugsly
                        Indinapolis,IN
 4-Oct-85 06:08:50-MDT,854;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 4 Oct 85 06:08:44-MDT
Received: from sdcsvax.arpa by AMSAA.ARPA id a010753; 4 Oct 85 7:34 EDT
Received: by sdcsvax.ARPA (5.5/4.41)
	id AA09354; Fri, 4 Oct 85 00:27:18 PDT hops=0
From: crash!kevinb@SDCSVAX.ARPA
Message-Id: <8510040727.AA09354@sdcsvax.ARPA>
Date: Thu, 3 Oct 85 22:46:06 PDT
To: Info-CPM@AMSAA.ARPA
Subject: CP/M 2.2 Autoload info needed

I can get an autoload at cold and warm boot time, but am seeking a way to
get a menu up at coldboot time only. How can I get my machine, an
Advanced Digital Super Quad, to do this? my CCP starts at DC00, according to
the PD program PROBE.COM.

	Thanks in advance,

Kevin J. Belles - UUCP {ihnp4,cbosgd,sdcsvax,noscvax}crash!kevinb
~~~~~ ~~ ~~~~~~ - ARPA crash!kevinb@{ucsd,nosc}.ARPA

 4-Oct-85 06:32:02-MDT,889;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 4 Oct 85 06:31:54-MDT
Received: from xerox.arpa by AMSAA.ARPA id a011437; 4 Oct 85 7:50 EDT
Received: from Muscat.ms by ArpaGateway.ms ; 04 OCT 85 04:52:46 PDT
Date: Fri, 4 Oct 85 07:52 EDT
From: Kushall.henr@XEROX.ARPA
Subject: Re: Wanted: Screen editor for CP/M on the C64.
In-reply-to: <575@isrnix.UUCP>
To: David Roth <pugsly%isrnix.uucp@BRL.ARPA>
cc: info-cpm@AMSAA.ARPA
Message-ID: <851004-045246-3186@Xerox>

This may sound silly, but TURBO PASCAL is available for the C64 CPM
option.
In fact TURBO-PASCAL is the only product ever offered for the C64 CPM
option.(on the Commodore disk format)

TURBO comes with a screen editor that mimics WS in the non-document
mode.
The editor works well and is fast. It is limited to files that can fit
in memory.

ED KUSHALL

 4-Oct-85 07:09:54-MDT,675;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 4 Oct 85 07:09:50-MDT
Received: from usc-isid.arpa by AMSAA.ARPA id a012295; 4 Oct 85 8:35 EDT
Date: 4 Oct 1985 00:13-EDT
Sender: ABN.ISCAMS@USC-ISID.ARPA
Subject: Re: Two CP/M Computers for Sale
From: ABN.ISCAMS@USC-ISID.ARPA
To: amc543%uiucuxa.uiuc.arpa@BRL.ARPA
Cc: info-cpm@AMSAA.ARPA
Message-ID: <[USC-ISID.ARPA] 4-Oct-85 00:13:52.ABN.ISCAMS>
In-Reply-To: <10100001@uiucuxa>

Oh NOOOOOO..

Not right in the middle of our quarterly "Shall There Be Ads" feud...

Is this salt in the wound or oil in the fire?

Regards,
David Kirschbaum
ABN.ISCAMS@USC-ISID
 4-Oct-85 07:12:35-MDT,1192;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 4 Oct 85 07:12:27-MDT
Received: from usc-isid.arpa by AMSAA.ARPA id a012301; 4 Oct 85 8:36 EDT
Date: 4 Oct 1985 00:19-EDT
Sender: ABN.ISCAMS@USC-ISID.ARPA
Subject: Re: Classified ads
From: ABN.ISCAMS@USC-ISID.ARPA
To: edelheit@MITRE.ARPA
Cc: hestenes%sdcsla.uucp@BRL.ARPA, info-cpm@AMSAA.ARPA
Message-ID: <[USC-ISID.ARPA] 4-Oct-85 00:19:22.ABN.ISCAMS>
In-Reply-To: <8510031405.AA12747@mitre.ARPA>

For what it's worth...

I concur with Jeff's comments on inappropriateness of private or any
other ads on the ARPANet.  (I'm sure DoD is vastly reassured and encouraged
by that.)

But I would hate to lose the ties/links with those other nets that work
with us on the ARPANet who DO permit these adds.  Regrettably, some people's
distribution schemas will shoot ads across to us .. a good application for
AI maybe?  To filter them out?  Any messages with "FOR SALE", "CHEAP",
"SUCH A DEAL"?

Regards,
David Kirschbaum
ABN.ISCAMS@USC-ISID
(and this net is my ONLY affiliation with the Govt except for my retirement
check and income taxes, so no disclaimers are required.)
 4-Oct-85 08:15:30-MDT,1409;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 4 Oct 85 08:15:14-MDT
Date:     Fri, 4 Oct 85 9:22:27 EDT
From:     David Towson (SECAD) <towson@AMSAA.ARPA>
To:       info-cpm@AMSAA.ARPA
Subject:  Re:  7000+ character tutorial on sending BREAK:

Fellow CP/Mers - I received the following note in response to my recently
posted tutorial on sending BREAK over serial asynchronous links:

	From: (Richard Kenner) <KENNER@NYU-CMCL1.ARPA>
	To: <towson@AMSAA.ARPA>
	Subject: RE: 7000+ character tutorial on sending BREAK:
	
	Minor correction to your very good lesson on asynch for those who
	believe the world started with the microcomputer:  The convention as
	I have always heard it is to default to 2 stop bits for baud rates
	150 and below, not 110 and below.  In field test versions of some DEC
	operating system (I think RSX, but am not sure), they also originally
	had 110 and changed it to 150 when I reported it to them.
	
     Thanks, Richard.  Anybody know what hardware was originally responsible
for the use of 150 baud?  110 baud was derived from a nominal rate of 10
characters-per-second, with 11 bits (one start, eight data and two stop) per
character (10 x 11 = 110).  150 baud appears to be based on 15 characters-per-
second with 10 bits (only one stop-bit) per character.  Who made the first 15
cps printer?


Dave

 4-Oct-85 09:59:08-MDT,1489;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 4 Oct 85 09:59:00-MDT
Received: from bbnccq.arpa by AMSAA.ARPA id a016530; 4 Oct 85 11:23 EDT
Date: Fri, 4 Oct 85 11:10:42 EDT
From: Bob Clements <clements@BBNCCQ.ARPA>
Subject: 150 baud terminals
To: David Towson (SECAD) <towson@AMSAA.ARPA>
Cc: info-cpm@AMSAA.ARPA, clements@BBNCCQ.ARPA

>> Anybody know what hardware was originally responsible for the
>> use of 150 baud? ... Who made the first 15 cps printer?

The first major printer at 150 baud  (maybe the first of all, I don't know)
was the Teletype model 37.  Its mechanism was a lot like the model 35,
but with a bigger type basket. It was Teletype's first
machine with lower case letters.  We used them on some of the early PDP-10
processors as consoles. [We = DEC engineering of about 1969.]

And the person who corrected the tutorial by saying that 150 baud
machines used two stop bits was wrong. The model 37 used one stop bit.

I think the 37 was the only machine I ever saw that was fully mechanical
at that speed. That is, the "UART" function (serial <--> parallel
conversion) was mechanical, not electronic.  It rattled its little heart
out at a good clip, but couldn't really stand up to the effort. They didn't
last long before wearing themselves out and dying.

/Rcc

ARPA:       CLEMENTS@BBN.ARPA
USENET:     {ihnp4, decvax, ...}!bbncca!clements
Ham Packet: K1BC
Telco:      617-497-3612

 4-Oct-85 11:02:58-MDT,1313;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 4 Oct 85 11:02:51-MDT
Received: from dca-eur.arpa by AMSAA.ARPA id a019773; 4 Oct 85 12:20 EDT
Date: 4 Oct 85 16:04:43 GMT
From: bower@dca-eur.ARPA
Subject: Re:  150 baud terminals
To: clements@BBNCCQ.ARPA
CC: info-cpm@AMSAA.ARPA

Must strongly disagree with the statement that Model 37's wear
out fast.  I have one (currently in storage) that was the ONLY printer
on my home system(s) for over 3 years, often printing large assembly
listings lasting over 6 hours.  As long as you gave them an annual oil
change and lube, they will last almost indefinately.  The one I have
is set for 10 pitch, although I understand some were 12-pitch, and
printed only 69 characters before inducing an automatic line feed.
   The 150 bps speed appears to be an early effort into the standard
rates governed by the "75 times 2 to the nth" rule comprised of 75, 150,
300, 600, 1200...etc bit rates.
   One quirk on some Model 37s is that many had the MIL-STD-188C inter-
faces which use a POSITIVE voltage for a logical "1" whereas RS-232 uses
a NEGATIVE voltage for a logical "1".  This means that an extra inverter
is required when driving the device from commonly available interfaces.
                Hal

 7-Oct-85 05:47:33-MDT,2712;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 7 Oct 85 05:47:25-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id ab06693; 7 Oct 85 7:20 EDT
Received: from usenet by TGR.BRL.ARPA id a006412; 3 Oct 85 23:59 EDT
From: Ted Emigh <emigh%ecsvax.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: SCAN -- a program to look at text and squeezed files
Message-ID: <512@ecsvax.UUCP>
Date: 1 Oct 85 15:30:46 GMT
To:       info-cpm@AMSAA.ARPA


                        SCAN Version 1.00

SCAN, based on the program BISHOW, is a program to view text and 
squeezed text files.   It can be used to take quick looks at files 
without unsqueezing them or loading a large text editor, or to 
examine another file with the RUN command while in Wordstar. 
You can display the file in either direction, search for
strings, or view only selected columns of the file.  In function, it
is identical to BISHOW Version 1.11 with two major additions  the
search function, and the ability to bishow a squeezed file.  The
program is written for Z80's only, and the addition of the unsqueezing
routines has ballooned the program to just under 4K.  The various
commands for SCAN are:

     1)   Display the Next Page (Forward a Page) 
     2)   Display the Previous Page (Back a Page)
     3)   Display the Next Line (Next Line)
     4)   Display the Previous Line (Back a Line)
     5)   Display the First Page (Top of File)
     6)   Display the Last Page (End of File)
     7)   Quit (End SCAN)
     8)   Set Screen Parameters
     9)   Search for a String of Characters
          Searching includes wild card characters, forward and
          backward search, and option to ignore upper/lower case.
    10)   Display Help

As distributed, SCAN contains a small patch file (SCANPAT.ASM). 
This allow changing the various default parameters, as well as 
the commands and terminal characteristics.  Look at this file for 
information about modifying SCAN.  The distributed version of 
SCAN is configured for the standard command names and a "plain 
vanilla" CRT.  This should work for most terminals.

If you are interested in the program, please E-mail me a message.
If there is enough interest, I will distribute it via net.sources,
otherwise I'll E-mail it back to you.  The normal distribution package
includes SCAN.DOC, SCANPAT.ASM, AND SCAN.HEX.  The sources is written
in Zilog mnemonics and is not being distributed at this time.
-- 

Ted H. Emigh     Genetics and Statistics, North Carolina State U, Raleigh  NC
USENET:	{akgua decvax duke ihnp4 unc}!mcnc!ecsvax!emigh
ARPA:	decvax!mcnc!ecsvax!emigh@BERKELEY
BITNET: NEMIGH@TUCC
 7-Oct-85 05:50:19-MDT,1290;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 7 Oct 85 05:50:13-MDT
Received: from ucb-vax.arpa by AMSAA.ARPA id a006813; 7 Oct 85 7:21 EDT
Received: by UCB-VAX (5.28/5.12)
	id AA04053; Sat, 5 Oct 85 15:10:31 PDT
Message-Id: <8510052210.AA04053@UCB-VAX>
Received: by ihnp4.ATT.UUCP id AA09824; 5 Oct 85 15:59:30 CDT (Sat)
Received: by inuxc.ATT.UUCP, id AA01183; 5 Oct 85 15:57:41 EST (Sat)
Date: Sat, 5 Oct 85 15:15:50 EST
From: David Roth <ihnp4!inuxc!isrnix!pugsly@ucb-vax.ARPA>
Received: by isrnix.UUCP; id AA29785; Sat, 5 Oct 85 15:15:50 EST
To: iuvax!seismo!XEROX.ARPA@ucb-vax.ARPA, pugsly%isrnix.uucp@BRL.ARPA
Subject: Re: Wanted: Screen editor for CP/M on the C64.
Cc: info-cpm@AMSAA.ARPA

No, I don't think that is silly at all.
My main reason for wanting the editor is to avoid using ED to create and edit .ASM files.
Does the editor with TURBO support .ASM and .TXT file type?
I also got a copy of VDO.hex that Keith Petersen was nice enough to send me
and I am going to try that out too.
Have to dig out that program that lets you xfer files from C64 DOS<=>C64 CP/M.

What does Turbo Pascal for the C64 CP/M cost?
Thanks in advance.
			David A. Roth
		...decvax!pur-ee!isrnix!pugsly
			Indianapolis,IN
 7-Oct-85 08:13:40-MDT,652;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 7 Oct 85 08:13:32-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a007210; 7 Oct 85 7:33 EDT
Date: Sat 5 Oct 85 05:19:59-MDT
From: Jim Forrest <JFORREST@SIMTEL20.ARPA>
Subject: Backup on VCR
To: INFO-CPM@SIMTEL20.ARPA, INFO-MICRO@SIMTEL20.ARPA
cc: JFORREST@SIMTEL20.ARPA
Message-ID: <12148663178.11.JFORREST@SIMTEL20.ARPA>

A friend of mine would like to know if there is a RELATIVELY
"easy and inexpensive" way to back up the hard disk on his Kaypro
10 to his VCR.
Appreciate response from anyone with expertise in this area.
Jim
-------
 7-Oct-85 08:18:04-MDT,1930;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 7 Oct 85 08:17:48-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a007859; 7 Oct 85 7:55 EDT
Received: from usenet by TGR.BRL.ARPA id a009276; 5 Oct 85 23:44 EDT
From: Chuck McManis <cem%intelca.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: D.R.C. S-100 RamDisk
Message-ID: <110@intelca.UUCP>
Date: 3 Oct 85 15:37:15 GMT
To:       info-cpm@AMSAA.ARPA

[No amount of incanting will entice my mailer to accept your address so we
 go to plan B, the news route. ]

> Have any of you used the 256K S-100 Solid State Disk Simulator (ramdisk)
> from Digital Research Computers ? If so, I would like to hear your comments.
> I am thinking about getting one since the price has dropped to less than $200.
> 
> They provide BIOS code for CP/M 2.2. Does anyone have a CP/M Plus version?
> Is it really S-100 (IEEE 696) compatible? Is it reliable?
> 
> I would appreciate any advice on this product/company.
> 
> thanks,
> 
>       Bob Haar

I have dealt with Digital Research Computers (of Texas) a couple of times
and had good results. The lab where I worked bought a bunch of their ZRT-80
boards to upgrade some otherwise scrap terminals. The only difficulty was 
in teaching them to handle a P.O. (they wanted to know how to "cash" it)
The boards worked fine on power-up so I can't say how they would handle a
service call. 

As for the RAM disk I keep seeing it and wondering if I should risk it. If
you do get one please post your experiences with it to the net.

--Chuck

-- 
                                            - - - D I S C L A I M E R - - - 
{ihnp4,fortune}!dual\                     All opinions expressed herein are my
        {qantel,idi}-> !intelca!cem       own and not those of my employer, my
 {ucbvax,hao}!hplabs/                     friends, or my avocado plant. :-}
 7-Oct-85 08:40:18-MDT,706;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 7 Oct 85 08:39:59-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a008059; 7 Oct 85 7:59 EDT
Received: from mit-mc.arpa by AOS.BRL.ARPA id a005519; 5 Oct 85 23:21 EDT
Date: Sat,  5 Oct 85 23:20:50 EDT
From: "Stephen C. Hill" <STEVEH@MIT-MC.ARPA>
Subject:  CRC procedure needed
To: INFO-MICRO@MIT-MC.ARPA, INFO-CPM@MIT-MC.ARPA, INFO-KERMIT@MIT-MC.ARPA
cc: STEVEH@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].669828.851005.STEVEH>

Does anyone have a version of the CRC error checking algorithm in C or Pascal?
I would like to put it in a version of KERMIT that I am writing for the State
of Illinois.

 7-Oct-85 08:40:59-MDT,780;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 7 Oct 85 08:40:49-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id aa07859; 7 Oct 85 7:55 EDT
Received: from usenet by TGR.BRL.ARPA id a013659; 6 Oct 85 2:44 EDT
From: "Robert A. Dukelow" <dukelow%noscvax.uucp@BRL.ARPA>
Newsgroups: net.micro.pc,net.micro.cpm
Subject: Looking for WATFOR compiler
Message-ID: <41@noscvax.UUCP>
Date: 2 Oct 85 00:08:44 GMT
Xref: seismo net.micro.pc:5942 net.micro.cpm:5065
To:       info-cpm@AMSAA.ARPA

Does anyone know if a compiler named WATFOR is available for either
PC-DOS or CP/M? If so, where? My daughter is learning it in her high
school class and would like to have it at home to make life easier.
--Bob Dukelow (dukelow@nosc)
 7-Oct-85 09:08:38-MDT,1066;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 7 Oct 85 09:08:27-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id aa06837; 7 Oct 85 7:21 EDT
Received: from usenet by TGR.BRL.ARPA id a002073; 4 Oct 85 20:14 EDT
From: cindy%ada-uts.uucp@BRL.ARPA
Newsgroups: net.micro.cpm
Subject: Re: Orphaned Response
Message-ID: <16800002@ada-uts.UUCP>
Date: 2 Oct 85 17:40:00 GMT
Nf-ID: #R:brl-tgr:-141400:ada-uts:16800002:177600:493
Nf-From: ada-uts!cindy    Oct  2 13:40:00 1985
To:       info-cpm@AMSAA.ARPA


    If you're talking about the MD-11 system from MORROW, there is a
phone number for their California office (415) 430-1970.  I called
recently since I'm having trouble with my hard disk.  For the Boston
area the nearest official Morrow service place is near Nashua NH.
They're Computer Data Services (or Systematic Solutions) (603) 673-7375
The Meeting Place Mall, Amherst, NH 03031.  They might be able to help
you.

NET: {harpo, allegro, bellcore, ihnp4}!inmet!ada-uts!cindy



----------
 7-Oct-85 09:09:12-MDT,1007;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 7 Oct 85 09:09:05-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a008068; 7 Oct 85 8:00 EDT
Received: from simtel20.arpa by AOS.BRL.ARPA id a008650; 6 Oct 85 15:52 EDT
Date: Saturday, 5 October 1985  22:34-MDT
Message-ID: <KPETERSEN.12149017280.BABYL@SIMTEL20.ARPA>
Sender: David Roth <ihnp4!inuxc!isrnix!pugsly@UCB-VAX.ARPA>
From: David Roth <ihnp4!inuxc!isrnix!pugsly@UCB-VAX.ARPA>
Subject:   Commodore 64 CP/M problem
ReSent-From: KPETERSEN@SIMTEL20.ARPA
ReSent-To: Info-Cpm@BRL.ARPA
ReSent-Date: Sun 6 Oct 1985 13:45-MDT

I had my C64 replaced with a new one about a month ago.  I didn't see
any new changes in the new C64 but I guess there is since my C64 CP/M
doesn't work now.  Does anyone know why?  I bought it in Nov. 83.  Of
course I might be stuck with it now, worst is that I can't run CP/M on
my c64 now.

			David A. Roth
	...decvax!pur-ee!isrnix!pugsly
			Indianapolis,IN
 7-Oct-85 09:11:02-MDT,1555;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 7 Oct 85 09:10:55-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a006877; 7 Oct 85 7:22 EDT
Received: from usenet by TGR.BRL.ARPA id a004184; 4 Oct 85 21:12 EDT
From: jp@LANL.ARPA
Newsgroups: net.micro.cpm
Subject: Re: D.R.C. S-100 RamDisk
Message-ID: <31283@lanl.ARPA>
Date: 2 Oct 85 05:42:03 GMT
To:       info-cpm@AMSAA.ARPA


I don't know about their RAM boards, but their ZRT-80 board is pretty good.
I don't know if the same person that designed the ZRT-80 (Bill White) did
the RAM boards or not.  But, if so, the RAM boards are probably pretty solid.

I have built three ZRT-80's from kits.  It's not a problem for someone
who has built similar boards before, but the manuals are definitely not
in the same category as those from Heathkit.  The instructions for the
ZRT-80 kit are three pages long.

One of the things I like about dealing with DRC is that, in the case of the
ZRT-80 board, they make the software source code available on a disk for
a reasonable price.  Also, the manual includes a nice writeup on how to
use it and how it works.

My only beef is that they always quote 2 weeks delivery, and they mean it.
I don't know if they sit on the orders for two weeks or if they are always
two weeks behind, but they deinitely do not ship your order the next day.
(maybe they are just very organized?)

If DRC had something that I wanted I would definitely give them an order.
     

Jim Potter  jp@lanl.arpa
 7-Oct-85 09:13:53-MDT,1338;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 7 Oct 85 09:13:45-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id aa06877; 7 Oct 85 7:22 EDT
Received: from usenet by TGR.BRL.ARPA id a006091; 4 Oct 85 22:02 EDT
From: The Polymath <hollombe%ttidcc.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: wanna buy TurboPascal for CP/M-80
Message-ID: <738@ttidcc.UUCP>
Date: 30 Sep 85 18:41:43 GMT
To:       info-cpm@AMSAA.ARPA

In article <111@birtch.UUCP> oleg@birtch.UUCP (Oleg Kiselev x258) writes:
>> Yes I know there's JRT, but  was told that it can be worse than useless ...)
>
>You were told correctly. Some time ago when I worked for UCLA Extension
>we bought JRT Pascal compiler for CPM2.2 on hp125. It stunk. Turbo Pascal
>was WAY better.  However, JRT had a new version of their compiler since
>then. ...

I've got it.  It still stinks.  I'm going to trash it and go with Turbo for
my next project.

-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
The Polymath (aka: Jerry Hollombe)
Citicorp(+)TTI                    Common Sense is what tells you that a ten
3100 Ocean Park Blvd.             pound weight falls ten times as fast as a
Santa Monica, CA  90405           one pound weight.
(213) 450-9111, ext. 2483
{philabs,randvax,trwrb,vortex}!ttidca!ttidcc!hollombe
 7-Oct-85 09:16:16-MDT,693;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 7 Oct 85 09:16:09-MDT
Received: from mit-multics.arpa by AMSAA.ARPA id a007005; 7 Oct 85 7:27 EDT
Date:  Fri, 4 Oct 85 20:20 EDT
From:  "Paul E. Woodie" <Woodie@MIT-MULTICS.ARPA>
Subject:  Osborne 1 Break
To:  info-cpm@AMSAA.ARPA
Message-ID:  <851005002032.238163@MIT-MULTICS.ARPA>

Although I have not checked it out, I assume that the overlays for the
MEX (and perhaps a few other ) modem program(s) for the O1 have the
assembly code for implementing a "break" using the uart chip in the O1.

These overlays can be found in the simtel20 archives:  micro:<cpm.mex>.

--Paul Woodie
 7-Oct-85 09:52:49-MDT,13564;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 7 Oct 85 09:51:46-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a007115; 7 Oct 85 7:31 EDT
Received: from simtel20.arpa by AOS.BRL.ARPA id a003177; 5 Oct 85 12:03 EDT
Date: 2 Oct 85 05:03:34 GMT
Message-ID: <KPETERSEN.12148714457.BABYL@SIMTEL20.ARPA>
Sender: "Ian D. Allen" <ihnp4!cbosgd!clyde!watmath!idallen@SEISMO.ARPA>
From: "Ian D. Allen" <ihnp4!cbosgd!clyde!watmath!idallen@SEISMO.ARPA>
Newsgroups: net.dcom
Subject: Description and Review of USR Courier 2400 bps modem
Organization: University of Waterloo
ReSent-From: KPETERSEN@SIMTEL20.ARPA
ReSent-To: Info-Cpm@BRL.ARPA
ReSent-Date: Sat 5 Oct 1985 10:01-MDT

Product description, evaluation, and bug report:

US Robotics Modem Courier 2400  (FCC CJE794)  Ser. #30-05816  ROM set #242

Bell 103/113 Bell 212-A CCITT V.22bis compatible (300/1200/2400 bps)
Approved by DOC Communications Canada 550 1169 A
Ringer Equivalence: 0.4   Canadian Modem Load Number 36B
Warranty: Two years.

Description:
- plastic case; help summary printed on the bottom; connections via rear
- on-line help screens for everything (AT$ ATS$ ATD$)
- all current modem settings displayable in an on-line table
- internal speaker; slide volume-control on right side of unit
- records duration of call, or use timer as real-time clock
- detailed call progress result codes (e.g. BUSY, RINGING, VOICE)
- automatically repeat-dial a busy line up to 10 times
- ability to dial alphabetic phone numbers, e.g. 1-800-DIAL USR
- outgoing baud rate set automatically according to terminal baud rate
- automatic switch from 2400 to 1200 if called modem is 1200
- optional adaptive DTMF (Touch Tone) dialling - optionally uses DTMF
  if line can handle it, otherwise uses pulse
- two RJ11C jacks; one for wall and one for phone
- can dial-out with Answer instead of Originate tones
- can toggle switch hook, e.g. to transfer a call
- can wait for second dial tone
- can wait for "answer" - silence after a ring
- optional fast dial-tone detect
- Morse Code capability - 1270Hz tone 62ms dot 186ms dash

Result Codes:
  OK
  CONNECT
  CONNECT 1200
  CONNECT 2400
  RING
  RINGING
  BUSY
  VOICE
  ERROR
  NO CARRIER
  NO ANSWER
  NO DIAL TONE

'AT' Command set:
	$	HELP Command Reference Screen (this list)
	S$	HELP S-register Reference Screen
	D$	HELP Dial Reference Screen

	A 	Force answer mode
	A/	Repeat last command
	AT	Prefix
	Cn	n=0 Transmitter OFF (modem becomes receive-only)
		n=1 Transmitter ON (normal operation)
	Ds	Dial telephone number
		s=0..9#* @WTPR,;"!
	En	n=0 No echo of commands
		n=1 Echo commands to screen
	Fn	n=0 Half Duplex-local echo
		n=1 Full Duplex-no local echo
	Hn	n=0 Hang up
		n=1 Go off-hook
	In	n=0 Show product code
		n=1 Do checksum
		n=2 RAM test
		n=3 Call duration/Clock
			I3=s Set Clock
				 s=Hours:Min:Sec
		n=4 Show current modem settings
	Kn	n=0 Call Duration mode
		n=1 Real Time Clock mode
	Mn	n=0 Speaker OFF
		n=1 Speaker ON until Carrier
		n=2 Speaker always ON
		n=3 Speaker OFF during Dial
	O	Return on-line after command
	Qn	n=0 Show result codes
		n=1 Suppress result codes
	Sr=n	Set register "r" to "n"
	Sr?		Query register "r" (see also I4)
	Vn	n=0 Numeric result codes
		n=1 Verbal result codes
	Xn	n=0 Standard result codes set (Hayes X0)
		n=1 Extended (1200) result code set (Hayes X1)
		n=2..6 Advanced result code sets
	Z	Software reset and reading of DIP switches
	>	Repeat command until cancelled; repeat Dial at most 10 times

S-Register Functions (can be set to 1..255):
	S0	Number of rings before answering
	S1	Counts number of rings
	S2	Set Escape-Code character
	S3	Set Carriage-Return character
	S4	Set Line-Feed character
	S5	Set Backspace character
	S6	Set Dial Tone wait time (seconds)
	S7	Set Carrier wait time (seconds)
	S8	Set Comma and Repeat pause time (seconds)
	S9	Set Carrier Detect recognition time (1/10 seconds)
	S10	Set Carrier Loss/Hang-up time (1/10 seconds)
	S11	Set Touch-Tone spacing (milliseconds)
	S12	Set Escape-Code guard time (1/50 seconds)
	S14	Smartcom 2.0 kludge to pretend modem is 1200 bps
	S16	0 = Data Mode
		1 = Analog Loopback
		2 = Dial Test
		4 = Test Pattern
		4 = Analog Loopback and Test Pattern

Dip Switches:
- DTR (pin 20) normal / DTR always on
- Verbal result codes / Numeric result codes
- Suppress result codes / Display result codes
- Echo off-line commands / Don't echo off-line commands
- Auto-answer on Ring / Suppress auto-answer
- Normal Carrier-Detect (pin 8) / Carrier-Detect always ON
- Single phone connection RJ11 / Multiple phone connection RJ12/RJ13
- Disable AT command set / Enable AT command set
- Disconnect with +++ / Can go back on-line after +++
- Reserved
- Pins 2 and 3 standard / Reverse pins 2 and 3

LED front-panel:
- High Speed (2400 bps communication)
- Auto Answer; Answer mode
- Carrier Detect
- Off Hook
- Receive Data
- Send Data
- Terminal Ready (DTR from terminal or with DTR over-ride ON)
- Modem Ready; Power
- Analog Loopback (self-test mode)

Initial Performance:

No errors during 10 hours at 2400 bps from home (1 crow mile from UofW) 
into some 2400 bps modem (make unknown) attached to Sytek network at 
UofW.  No errors when using the Courier to dial out from MATH into the 
Sytek at 2400bps and then logging back into MATH again. Many errors on 
MATH end during two of several 1200 bps calls into WATMATH ttyd0 
(Gandalf/Cermetek SAM 212A modem).  The errors were always BREAK 
followed by a "{".  Unlike the Hayes 1200 modem I normally use, taking 
an extension phone off the hook at 1200bps made the MATH errors much 
worse rather than better.  (The Hayes 1200 is virtually error-free with 
the phone off the hook at 1200bps.)  Calling in to MATH and ROSE modems 
(Gandalf/Cermetek SAM 212A modems) produced lots and lots of noise when 
I tried calling out and back in using the Courier at 1200bps.  Using 
the Courier to call in to WATCGL, WATDAISY, and WATMUM (Vadic 3451 
modems) showed no noise.  As I said, at 2400bps, calling out from MATH 
into the unknown 2400 bps modem using the Courier showed no noise at 
all.

UUCP

Our byte rate to ihnp4 in Chigago is usually about 70-90 bytes/sec at 
1200 bps; using the 2400 bps Courier changed that up to about 145 
bytes/sec. Looking at the amount of illumination of the send/receive 
data LEDs, I get the feeling that the limiting factor is still the load 
on ihnp4, not the speed or quality of the line or modem.  ihnp4 would 
not respond for long periods of time; this would often cause our end to 
time out.  I babysat the modem and kept calling back whenever this 
happened. ihnp4 has an ARK 2400 bps modem inbound, and uses a Concord 
outbound.

In town here, we do a maximum of 110 bytes/sec at 1200 bps; using the 
Courier upped that to about 215 bytes/sec.  If they ever start charging 
for local calls, the higher speed will be useful.

Calling utzoo in Toronto, our 1200 bps byte rate is about 109 
bytes/sec.  I tried to use the Courier into their 2400 bps modems (they 
have a Racal-Vadic 2400PA), but the noise on the line usually prevented 
the login from succeeding.  In the rare cases where it did succeed, the 
error rate was so high that the byte rate was only 24 bytes/sec, with 
so many timeouts that the overall rate was less than half that.  1200 
bps on the same line, a UofW FX Toronto line, worked just fine.  I 
tried avoiding the FX line and just dialling long distance and got 
about the same error rate, so I don't think it's the FX line that's 
awful.  (After all, we call ihnp4 at 1200 and 2400 bps using the same 
set-up with much better results.)

I put the Courier onto its own dedicated phone line, getting it off the 
UofW SL-1 extension altogether, and called utzoo again.  Byte rate went 
up to 150 bytes/sec, provided I could get logged in.  Still lots of 
noise on the line.

I called linus (Boston), who have Concord Data 2400 bps modems, and 
noticed no noise on the line during the brief call there.  I sent them 
/etc/termcap (74355 bytes) and got a byte rate of 210 bytes/sec. (Very 
Nice!)  I called utai (Toronto) briefly, and noticed no noise there 
either.  (No uucp account, so I couldn't send anything.)

To sum up: it seems the University's SL-1 switch might be damaging 
communications a bit.  Regardless of that, the Courier just doesn't 
like talking to the Vadic at utzoo at 2400 bps no matter what line I 
use.  The Courier calls all four other 2400 bps modems I know of okay.  
henry@utzoo says their 2400 bps calls to linus average over 200 
bytes/sec both ways; we seem to do the same to linus, but can't talk to 
utzoo.  Just shows that things that can talk to the same thing can't 
necessarily talk to each other!

Observed Quirks with this modem:

If you are connected to something at 2400bps, you use +++ to get back 
to the command mode, you display and *interrupt* a HELP menu, then go 
back on line, you get lots of repeating junk on your screen.  You have 
to use +++ to go off-line again, display a HELP menu *without 
interruption*, then go back on line.  If you try the same thing at 
1200bps, you get *no* junk if you interrupt the HELP menu and go back 
on line, and you get the repeating junk if you let it finish and go 
back on line!  At 1200 bps, I had the modem hang three times when this 
junk started appearing.  When the junk is printing, the Receive Data 
light is flashing madly and pulling out the phone cord gives an 
immediate NO CARRIER.  When the modem hung, the RD light went out, the 
SD light would flash when characters were typed, but nothing appeared 
on the screen and +++ and AT had no effect.  Pulling out the phone cord 
did not affect the hung modem; it just did not respond to anything and 
I had to power down every time.  Looks like you'd better not need any 
on-line help screens in the middle of a session.

We took the modem to a country exchange, long distance to UofW, and saw 
the same sort of junk appear when we tried calling the unknown 2400 bps 
modem at UofW.  The 2400 would answer, signal 2400 bps, and the Courier 
would respond with CONNECT 1200 (!?) and then lots of incessant junk.  
We usually had to power off the modem to get it back.  The incessant 
junk looked the same as the junk that kept spewing out in the above-
mentioned help-menu bug.  It's almost as if the answering modem were 
sending a 2400 bps carrier that the Courier was mis-interpreting at 
1200 bps, resulting in a continuous stream of junk. Actually using the 
Courier to call out at 1200 bps on the same country line worked just 
fine.

Nothing I tried could get the modem to recognize my VOICE in the 
extended result code set.  I set parameter X6 and phoned from my home 
line to my data line and answered the phone myself - the Courier said 
RINGING and then eventually NO CARRIER, no matter what I said into the 
phone. A friend tried the same thing and yelled a few times into the 
phone, and it recognized his voice as VOICE.

I picked up my extension phone, dialed a '5' to get rid of the dial 
tone, and then told the Courier to dial a number on the same line.  If 
I said nothing, it would correctly detect NO DIAL TONE.  If I talked 
while it came off-hook, it would usually mistake my voice for a dial 
tone, dial the number into my voice, and then say either BUSY or 
RINGING followed eventually by NO CARRIER.

Register S10 (timer for loss of carrier) claims to be scaled in tenth-
seconds, but setting it to 254 and unplugging the telephone cable 
causes carrier loss after only a second or two, not 25 seconds. Setting 
S10 to 255 and unplugging the cable hangs the modem.  It gets stuck 
off-hook with the CD light on, and refuses to respond to anything 
except power-off, even with the cable plugged in again.

The manual says you can type the command set in upper or lower case. 
What it doesn't say is that both letters of the AT prefix must be the 
*same* case -- "AT" and "at" work; "aT" and "At" do not.

"A/" repeats the last command, and the last command is cleared the 
instant the letters AT appear, so if you intended to repeat the last 
command but type AT followed by backspace followed by /, it's too late.  
Backspace only deletes command chars, not the prefix itself. This is a 
"feature" of Hayes modems, too.

The "guard band" register (S12) behaves a bit non-intuitively when set 
to small values.  Not only does the guard band decrease, but the length 
of time in which you have to type all three "+"s goes down too!  At 
small settings, you have to use the repeat key to get it fast enough. 
At the smallest settings, I think you're required to type the "+"s 
faster than the baud rate will allow...

Summary:

I could have put up with the help-menu problem if I hadn't also tripped 
over similar junk when using the modem in the country.  Looks like the 
modem's state transition diagram has a loophole.  UofW needs a modem 
that can talk 2400 bps to utzoo in Toronto, ideally using the cheap FX 
line through the UofW SL-1 exchange, and this one can't do that very 
well.  (In fact the ratio of line costs, FX versus using DDD on a 
private line, is almost exactly the ratio of byte rates, meaning we 
save no money going to 2400 bps on the DDD line instead of using 1200 
bps on the FX line.)

-IAN
 7-Oct-85 13:10:28-MDT,789;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 7 Oct 85 13:10:20-MDT
Received: from xerox.arpa by AMSAA.ARPA id a020627; 7 Oct 85 14:39 EDT
Received: from Muscat.ms by ArpaGateway.ms ; 07 OCT 85 10:57:32 PDT
Date: Mon, 7 Oct 85 13:01 EDT
From: Kushall.henr@XEROX.ARPA
Subject: Re: Looking for WATFOR compiler
In-reply-to: <41@noscvax.UUCP>
To: "Robert A. Dukelow" <dukelow%noscvax.uucp@BRL.ARPA>
cc: info-cpm@AMSAA.ARPA
Message-ID: <851007-105732-1146@Xerox>

WATFOR stands for WATerlooFORtran and is an interactive Fortran interputer.
It was developed by Waterloo University in Canada.

The first machine to use it was the Commadore 9000 (Super PET).
I don't know if ever was made available for any other machines.

Ed

 7-Oct-85 13:38:00-MDT,1410;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 7 Oct 85 13:37:53-MDT
Received: from xerox.arpa by AMSAA.ARPA id a020651; 7 Oct 85 14:40 EDT
Received: from Muscat.ms by ArpaGateway.ms ; 07 OCT 85 10:58:00 PDT
Date: Mon, 7 Oct 85 13:15 EDT
From: Kushall.henr@Xerox.ARPA
Subject: Re: Wanted: Screen editor for CP/M on the C64.
In-reply-to: <8510052210.AA04053@UCB-VAX>
To: David Roth <ihnp4!inuxc!isrnix!pugsly@ucb-vax.ARPA>
cc: iuvax!seismo!XEROX.ARPA@ucb-vax.ARPA, pugsly%isrnix.uucp@BRL.ARPA,
 info-cpm@AMSAA.ARPA
Message-ID: <851007-105800-1147@Xerox>

David:

To the best of my knowledge there is nothing unique about .ASM and .TXT
files, that is they are sequential ASCII text files. Using the
TURBO-PASCAL etitor you can give a file any name and extension that is a
legal CP/M file name. Thus you should be able te create and edit .ASM
and .TXT files with out any problems. In fact the TURBO editor can make
a file of the type NAME.COM but CP/M won't like it! The only restriction
is the file size is <62K (the manual says 64K) and the file must fit in
available memory, thus on CP/M 80 systems the file size will be much
less than 62K by the size of TURBO and the resident CP/M RAM space.

When you do a save from the TURBO editor the existing file NAME.EXT is
renamed NAME.BAK and a new NAME.EXT file is created.

Ed Kushall

 7-Oct-85 13:59:31-MDT,1228;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 7 Oct 85 13:59:22-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a020716; 7 Oct 85 14:42 EDT
Received: from usenet by TGR.BRL.ARPA id a026304; 7 Oct 85 13:53 EDT
From: jp@LANL.ARPA
Newsgroups: net.micro,net.micro.cpm,net.micro.pc,net.lang.pascal,net.sources
Subject: SoftWare Tools in Pascal posted to net.sources
Message-ID: <31464@lanl.ARPA>
Date: 6 Oct 85 04:54:04 GMT
Xref: seismo net.micro:12947 net.micro.cpm:5079 net.micro.pc:5951 net.lang.pascal:383 net.sources:3605
To:       info-cpm@AMSAA.ARPA





I have received several requests for copies of Software Tools in
Pascal that I recently received by e-mail.  Since some of the requests
were from sources that our mailer has been unable to find a return
path I am posting the Software Tools in Pascal to net.sources.

I am interested in adapting the Tools to run under Turbo Pascal.  If 
anyone else is interested in pursuing this, as a least one person has indicated,
please contact me and perhaps we can share the task.

Jim Potter  jp@lanl.arpa
            (505) 667-9615 work
            843-9615 work - FTS
            (505) 6625804 home
 7-Oct-85 14:28:57-MDT,1348;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 7 Oct 85 14:28:49-MDT
Received: from xerox.arpa by AMSAA.ARPA id a022211; 7 Oct 85 15:12 EDT
Received: from CheninBlanc.ms by ArpaGateway.ms ; 07 OCT 85 11:58:56 PDT
Date: 7 Oct 85 10:48:26 PDT (Monday)
From: Bicer.ES@XEROX.ARPA
Subject: IBM <==> Compupro/Viasyn
To: INFO-IBMPC@USC-ISIB.ARPA
cc: XeroxInfoIBMPc^.ES@XEROX.ARPA, info-cpm@AMSAA.ARPA, Bicer.ES@XEROX.ARPA, 
    WantAds^.ES@XEROX.ARPA, info-micro@BRL-VGR.ARPA
Reply-To: Bicer.ES@XEROX.ARPA
Message-ID: <851007-115856-1256@Xerox>


Hi,

Recently, I have started programming on an IBM PC, and have the following
problem:

I have a Compupro/Viasyn 816 at home, which is an S-100 machine. For my work, 
I need an IBM PC compatible system.

I know that I can buy a PC board, more memory and a hard disk for my system,
but the price tag is too high. So, what I'd like to find out is:

1- Is there a cheaper way to convert a Compupro into an IBM PC compatible machine?
2- Is it possible to trade in or exchange my sytem for a PC or a compatible?
3- If possible, what steps should I take to sell my system?

I need to resolve this issue as quickly as possible, so please, any info will
be greatly appreciated.

	Thanks in advance,
	Jack Bicer
	Bicer.ES@XEROX.ARPA
 8-Oct-85 05:49:46-MDT,2580;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 8 Oct 85 05:49:38-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a000922; 8 Oct 85 7:23 EDT
Received: from usenet by TGR.BRL.ARPA id a016157; 8 Oct 85 2:51 EDT
From: "G.PECKHAM" <gtp%hounx.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Computer for Sale
Message-ID: <376@hounx.UUCP>
Date: 7 Oct 85 14:41:19 GMT
To:       info-cpm@AMSAA.ARPA

I am selling a Zenith Z90 computer system for $2000.
In addition to being a good CPM machine, the system is great for
experimenting. The Zenith manuals detail everything both hardware
and software.



TOTAL PACKAGE PRICE:	$1500
**************************************

The System includes the following and more:
                                                         (Original)
ITEM							Retail Price

Hardware:
Zenith Z90 computer					$ 3195.00
	64k ram
	2 - 5.25" hard sectored drive (100k)
	1 - 5.25" soft sectored drive (620k)
		  dbl. sided, dbl. density

	1 - 10 Meg.byte Winchester drive		  2495.00


	approx. 80 diskettes				   240.00

Software:
Operating Systems -
	CPM 80						   150.00
	HDOS						   150.00
	ZCPR2	public domain, unix like system		      nc

Languages -
	C - Whitesmith's				   630.00
	Plink II (linker for above)			   350.00
	Mbasic 80 interpreter				   175.00
	Mbasic 80 compiler				   250.00
	Cbasic						   150.00
	Fortran 80					   195.00
	Cobol 80					   395.00
	USCD Pascal					   395.00
	Mac 80						    85.00

Database systems -
	FMS/80						   995.00
	Dbase II					   700.00
	Datastar					   295.00

Word Processing -
	Wordstar					   395.00
	Magic Wand					   295.00

Spreadsheet -
	Supercalc					   295.00
	
Accounting Pkgs. -
	Accounting Plus G/L, A/R, A/P, Payroll		  1900.00
	Peachtree G/L, A/P				   790.00

Demo pkgs. for sales support -
	Accounting Plus G/L, A/R, A/P, Payroll,		   175.00
	Sales Order, Purchase Order, Inventory,
	Point of Sale.
	Professional Time Acctg.			    60.00
	PK Attorney Time & Billing			    75.00
	DAGAR's Pharmacy System				   125.00

Misc. -
	all types of games, disk utilities,			-
	etc.

							____________

TOTAL retail value					 $14,955.00					
I am selling this all as a pkg. for $1500.00
The system is in mint condition and works perfectly.
The system is 2.5 yrs old.


If you are interested please send me mail or call me.
Home number (201) 367-1688,
Work number (201) 949-1831.

Gary Peckham
N.J.

hounx!gtp   or   houxf!hounx!gtp   or   ihnp4!hounx!gtp
 8-Oct-85 06:55:56-MDT,1170;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 8 Oct 85 06:55:50-MDT
Received: from uci-icsc.arpa by AMSAA.ARPA id a003042; 8 Oct 85 8:18 EDT
Received: from localhost by UCI-ICSC.ARPA id a017223; 7 Oct 85 15:04 PDT
To: Kushall.henr@XEROX.ARPA
cc: "Robert A. Dukelow" <dukelow%noscvax.uucp@BRL.ARPA>, info-cpm@AMSAA.ARPA, 
    young@UCI-ICSC.ARPA
Subject: Re: Looking for WATFOR compiler
In-reply-to: Your message of Mon, 7 Oct 85 13:01 EDT.
	     <851007-105732-1146@Xerox>
Date: 07 Oct 85 15:02:56 PDT (Mon)
From: Michal Young <young@UCI-ICSC.ARPA>


WATFOR was NOT first implemented on the SuperPET. It's immediate successor,
WATFIV, is mentioned in the 1979 edition of the dragon book (Aho and
Ullman), so WATFOR was around a long time before SuperPET. The version I am
aware of was available on IBM mainframes and was not an interpreter;  it was
a very fast compiler optimized for handling multiple compiles submitted in a
batch.  It was specially designed for student use, concentrating on quick
compile and good error checking rather than optimized object code.  

--Michal Young, young@uci

 8-Oct-85 07:18:30-MDT,565;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 8 Oct 85 07:18:26-MDT
Received: from brl-vat.arpa by AMSAA.ARPA id a004080; 8 Oct 85 8:39 EDT
Date:     Tue, 8 Oct 85 8:40:21 EDT
From:     Earl Weaver (VLD/ASB) <earl@BRL.ARPA>
To:       Kushall.henr@XEROX.ARPA
cc:       "Robert A. Dukelow" <dukelow%noscvax.uucp@BRL.ARPA>, info-cpm@AMSAA.ARPA
Subject:  Re:  Looking for WATFOR compiler

I used WATFOR/WATFIV back in '72 on U of Mich's IBM 360/67.  Presumably that
predates the "Commadore 9000 (Super PET)."
 8-Oct-85 08:14:54-MDT,1273;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 8 Oct 85 08:14:28-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a007810; 8 Oct 85 9:40 EDT
Received: from mit-mc.arpa by AOS.BRL.ARPA id a008615; 8 Oct 85 9:37 EDT
Received: from Xerox.ARPA by MIT-MC.ARPA  8 Oct 85 09:33:22 EDT
Received: from Muscat.ms by ArpaGateway.ms ; 08 OCT 85 06:31:05 PDT
Date: Tue, 8 Oct 85 09:30 EDT
From: Kushall.henr@XEROX.ARPA
Subject: Re: CRC procedure needed
In-reply-to: <[MIT-MC.ARPA].669828.851005.STEVEH>
To: "Stephen C. Hill" <STEVEH@MIT-MC.ARPA>
cc: INFO-MICRO@MIT-MC.ARPA, INFO-CPM@MIT-MC.ARPA, INFO-KERMIT@MIT-MC.ARPA
Message-ID: <851008-063105-1948@Xerox>

Steven:

There was a very good article that included this in the June 85 Dr.
Dobbs Journal. The article title is "Christensen Protocols in C" by
Donald Krantz.
The article starts on P66 and there is a special section on CRC on p.68.
This CRC is based on the CCITT polynomial X^16+X^12+X^5+1 (Someone must
know what that means). 

The Source Code in C for the entire XFR communications package can be
downloaded from the TCOG BBS (612) 724-7779 @300/1200 baud

Perhaps this article and code can help you with a KERMIT version of CRC.

Ed Kushall


 8-Oct-85 12:54:42-MDT,1430;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 8 Oct 85 12:54:21-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a016139; 8 Oct 85 14:02 EDT
Received: from usenet by TGR.BRL.ARPA id a002097; 8 Oct 85 13:50 EDT
From: "Colin Campbell [DCS]" <campbell%watdcsu.uucp@BRL.ARPA>
Newsgroups: net.micro.pc,net.micro.cpm
Subject: Re: Looking for WATFOR compiler
Message-ID: <1724@watdcsu.UUCP>
Date: 7 Oct 85 15:13:53 GMT
Xref: seismo net.micro.pc:5960 net.micro.cpm:5087
To:       info-cpm@AMSAA.ARPA

> Does anyone know if a compiler named WATFOR is available for either
> PC-DOS or CP/M? If so, where? My daughter is learning it in her high
> school class and would like to have it at home to make life easier.
> --Bob Dukelow (dukelow@nosc)

WATFOR77 is available for PC-DOS from:
        WATCOM Products Inc
        415 Phillip Street
        Waterloo, Ontario, Canada
        N2L 3X2
        (519) 886-3700
        Telex 06-955 458
It is available for other systems, too (e.g. IBM VM/CMS), but I don't
think it runs under CP/M.  It supports the full FORTRAN 77 standard.
Your daugther may be using WATFOR on a DEC mini in which case I believe
it would be a FORTRAN 66 compiler (from the same people).  (btw WATCOM
Products markets software developed by the WATCOM Group, as well as
software developed at the University of Waterloo - where I am employed.)
 8-Oct-85 13:18:08-MDT,1665;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 8 Oct 85 13:17:50-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a017023; 8 Oct 85 14:22 EDT
Received: from mit-mc.arpa by AOS.BRL.ARPA id a019023; 8 Oct 85 13:54 EDT
Received: from isi-vaxa.ARPA by MIT-MC.ARPA  8 Oct 85 13:49:00 EDT
Received: by isi-vaxa.ARPA (4.12/4.7)
	id AA17910; Tue, 8 Oct 85 10:09:14 pdt
Message-Id: <8510081709.AA17910@isi-vaxa.ARPA>
Date:  8 Oct 1985 1009-PDT (Tuesday)
To: "Stephen C. Hill" <STEVEH@MIT-MC.ARPA>
From: berman@ISI-VAXA.ARPA
Cc: INFO-MICRO@MIT-MC.ARPA, INFO-CPM@MIT-MC.ARPA, INFO-KERMIT@MIT-MC.ARPA

> Steven:

> There was a very good article that included this in the June 85 Dr.
> Dobbs Journal. The article title is "Christensen Protocols in C" by
> Donald Krantz.
> The article starts on P66 and there is a special section on CRC on p.68.
> This CRC is based on the CCITT polynomial X^16+X^12+X^5+1 (Someone must
> know what that means). 

> The Source Code in C for the entire XFR communications package can be
> downloaded from the TCOG BBS (612) 724-7779 @300/1200 baud

> Perhaps this article and code can help you with a KERMIT version of CRC.

> Ed Kushall

Warning:  I just implemented CRC from this article, and it is vague in
one serious point:  It says simply that the CRC is generated by running "each
byte of the packet" through the generator.  In Christensen protocol, this 
would normally include the header info, as when calculating checksum, but
(at least in Christensen) for CRC you only want the actual data bytes to
be CRC'd.

Note:  Your mileage may differ.

RB

 9-Oct-85 06:07:03-MDT,935;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 9 Oct 85 06:06:55-MDT
Received: from wiscvm.arpa by AMSAA.ARPA id a025439; 9 Oct 85 7:22 EDT
Received: from (MAILER)UCF1VM.BITNET by WISCVM.ARPA on 10/08/85 at
  22:10:56 CDT
Return-path: WOODRUFF%UCF1VM.BITNET@WISCVM.ARPA
Received: by UCF1VM (Mailer X1.21) id 7340; Tue, 08 Oct 85 22:32:32 EST
Date:         Tue, 8 Oct 85 22:27 EST
From:           Mark <WOODRUFF%UCF1VM.BITNET@WISCVM.ARPA>
Subject:      CRC checking and more
To:  INFO-CPM@AMSAA.ARPA
MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA

A recent issue of Dr. Dobbs Journal (was it August?  September?)
contained a good example of CRC checking.  Dr. Dobbs' frequently
publishes interesting things for CP/M programmers.  Check it out.

Regards,
Mark.

P.S. Does anyone know why the "==" line of mail files is 73 characters
     long by default?
 9-Oct-85 06:32:29-MDT,4607;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 9 Oct 85 06:32:15-MDT
Received: from mit-mc.arpa by AMSAA.ARPA id aa25442; 9 Oct 85 7:24 EDT
Date: Wed,  9 Oct 85 05:49:29 EDT
From: "Paul R. Grupp" <GRUPP@MIT-MC.ARPA>
Subject:  CRC in C (Nov 83 rerun)
To: info-cpm@AMSAA.ARPA
Message-ID: <[MIT-MC.ARPA].673383.851009.GRUPP>

Someone recently asked for CRC code in C but I've forgotten
who.  So here it is again.

Date: 9 Nov 83 5:35:04-PST (Wed)
From: harpo!floyd!clyde!burl!hou3c!hocda!machaids!djj at ucb-vax

About a month ago I put a  request  for  CRC  (Cyclic  Redundancy
Codes)  information  on this net.  I received in a number of good
programs and comments, and several requests to forward whatever I
discovered.   Since  I have not been able send mail to several of
the people who made requests, I'll put this summary on the net.

It appears that CRC calculations are based on a  polynomial  that
is  not standardized, so it is possible to have several different
valid CRC values for the same  file  simply  by  using  different
polynomials.   There  is  an article in the June 83 issue of IEEE
Micro which gives a little background on CRC and on a method  for
calculating  same.   Unfortunately,  the  examples  are  given in
assembler.

One of the C programs I received, and modified slightly  produces
CRC  values  identical to those produced by CRCK.COM and "uc" the
UNIX/CPM communications  program  that  is  intended  to  replace
"umodem".  Here is the source code ---- "crck.c" (118 lines;  493
words; 2874 bytes):
/*
 *			----	crck.c    ----
 *
 *			Version 1.0  -  4/9/83
 *
 *	This UN*X program performs a file hashsum calculation consistent
 *	with the de facto standard (but misnamed) "CRCK" program for CP/M.
 *
 *	Usage: crck [-w] filename...
 *
 *		The -w flag suppresses the warning message that normally
 *		is printed when a file is found not to be a multiple of
 *		128 bytes in size.  (Such a file cannot be a faithful copy
 *		of a CP/M file, since CP/M files are always a multiple of
 *		128 bytes).
 *
 *	Notes:
 *		1. Two versions of the CRCK program exist in the CP/M
 *		world. Variants of Keith Petersen's original program
 *		are the de facto standard, even though they misuse the
 *		underlying CRC calculation subroutine and therefore don't
 *		really perform a "CRC" function.  This program produces
 *		hashsums consistent with Petersen's scheme, currently
 *		found in the "CRCK4x.ASM" series.
 *
 *		2. In order for valid comparisons to be made between the
 *		CP/M and UNIX copies of a file, the file must, of course,
 *		have been transferred intact; i.e., with the "-rb" option
 *		of umodem, or the "-b" option of rb.
 *
 *							Jeff Martin
 *							Naperville, Il.
 *							4/9/83
 *	Version 1.1 -- djj  Oct 13, 1983
 *		Changed output print format, to make it more readable!
 *			Don Jackowski, Mine Hill, NJ
 */
#include	<stdio.h>
#include	<fcntl.h>
#define	CPMSEC	128

main(argc, argv)
int	argc;
char	*argv[];
{
	int	c, fdi, warn, wflg;
	char	*s, *in_file;
	char	cbuf[CPMSEC];
	unsigned crc, crck();

	warn = 1;
	while (--argc > 0 && (*++argv)[0] == '-') {
		for (s = argv[0]+1; *s != '\0'; s++) {
			switch (*s) {
				case 'w':
					warn = 0;
					break;
				default:
					printf("illegal option: '%c'\n", *s);
					argc = 0;
					break;
			}
		}
	}
	if (argc < 1) {
		printf("Usage: crck [-w] filename...\n");
		exit(1);
	}
	
	while (argc-- > 0) {
		in_file = (argv++)[0];
		fdi = open(in_file, O_RDONLY);
		if (fdi < 0) {
			printf("Cannot access %s\n", in_file);
			continue;
		}
		crc = wflg = 0;
		while ((c = read(fdi, cbuf, CPMSEC)) > 0) {
			if ((c != CPMSEC) && warn) {
				wflg++;
			}
			crc = crck(cbuf, c, crc);
		}
		printf("%14s --> %04X", in_file, crc);
		if(wflg)printf(" <-- not CP/M sector sized.\n");
		else	printf("\n");
		close(fdi);
		continue;
	}
}

/*
 * The only good thing to be said about the following function is that
 * it faithfully emulates the 8080 code in the CRCK4x.ASM series.  It
 * does NOT perform a CRC calculation, but does a rather bizarre hash
 * sum.
 */
unsigned
crck(buf, size, oldcrc)
char *buf;
int size;
unsigned oldcrc;
{
	register unsigned newcrc, tmp;
	register int i, qbit;
	
	newcrc = oldcrc;
	for (i = 0; i < size; i++) {
		qbit = newcrc & 0x8000;
		newcrc <<= 1;
		tmp = (newcrc + *buf++) & 0xff;
		newcrc = (newcrc & 0xff00) | tmp;
		if (qbit) {
			newcrc ^= 0xA097;
		}
	}
	return (newcrc);
}

 9-Oct-85 07:23:30-MDT,3012;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 9 Oct 85 07:23:22-MDT
Received: from usc-isi.arpa by AMSAA.ARPA id a027795; 9 Oct 85 8:31 EDT
Date:  9 Oct 1985 02:07:04 EDT
Subject: SB180 quirks
From: Rex Buddenberg <BUDDENBERGRA@USC-ISI.ARPA>
To: info-cpm@AMSAA.ARPA
cc: BUDDENBERGRA@USC-ISI.ARPA

Some experiences with the Ciarcia SB180 computer board.
The SB180 board has some gotchas attached.  It is a solid machine,
but not without some rough edges.  Here is what a couple of us have
found:
	Reset.  A cold boot doesn't always.  The system is supposed
to come up in monitor if no disk is present in A: (or no drives
attached).  System is supposed to reboot CPM if the disc is loaded.
In both cases, it often takes several resets to get action.
	Discs.  Read the manual carefully.  Few drives come correctly
configured out of the box.  If you put an 8" drive on the system
(eg as C:), you gotta turn it on every time you use the machine.
If you don't (or turn it off without shutting down the rest of the
system), you get this Gawd-awful buzz in the 5" drives.
	Configuration.  I hooked up a couple Qume 542's and found
that you want to pull ALL the shunts except the drive
select strap.  Regarding 8" drives, a Qume DT8 came up
OK after fiddling around with the settings for a bit.  
A Tandon half height has yet to decide to cooperate.
	Kermit.  And modem programs.  Haven't yet figured out the
I/O.  The CP4 'generic' Kermit will not talk to the modem for
some reason.  Yes, I tried all the port settings.
If someone gets a Kermit front end for this thing, let me
know...  
	ASCI ports.  You get a terminal and a modem port.  The basic
bits come right out of the 64180 and only the 1488/1489 RS-232
drivers are between your terminal and the CPU.  Which is just
enough.  My printer is wired as a DTE, but the modem is a DCE.
So to avoid fooling around with null modems and such, try this.
Get a 26 pin crimp-on connector to attach the
ribbon to the board.  Get your length of ribbon cable and crimp
the connector to it in the middle.  Then wire each end to the
DB-25s however you need them.  I got one female DTE and one male
DCE so both peripherals plug in correctly.  
	Z-DOS.  You have to sort thru all the stuff on the masters
and figger out that you don't need the 4 directory programs
supplied -- 1 will do nicely.  Unfortunately there isn't a lot of help
in setting up a usable working disc configuration.  Take out
too much and you get warmed over CPM.  Put in too much and you have
disc-bloat.  Not obvious where to discriminate.  But I guess this
is a bit like inheriting your million and not knowing where to
spend it all.
	There is no readily apparent way to get from CPM to the monitor.
The reverse is obvious.  
	Summary.  This board did not come up quite as slickly as my
AMPRO Little Board, which has become my workhorse for
general stuff.  But it is in the same league.  
		b
-------
 9-Oct-85 07:46:10-MDT,942;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 9 Oct 85 07:46:05-MDT
Received: from crdc-vax2.arpa by AMSAA.ARPA id a028826; 9 Oct 85 9:07 EDT
Date:     Wed, 9 Oct 85 9:08:45 EST
From:     "Jack H. Smith" <jhsmith@crdc-vax2.ARPA>
To:       info-cpm@AMSAA.ARPA
Subject:  watfor compiler 

	Bob,

		You might try SSS fortran, 'Small System Services', Super-
	soft Fortran IV Extended with Ratfor. As a reference manual, it 
	suggests 'Fortran IV with Watfor & Watfiv', a text that I used 
	in 1971 in high school. 'SSS Fortran' has most of the features 
	of Watfor or Watfiv except for the inherent differencs caused
	by implementation on an 8-bit micro. It runs on my Intertec 
	Compustar which is running standard CP/M 2.2.
		Supersoft's address is P.O. Box 1628, Champaign, IL 
		zip 61820 and phone is 217-359-2112....

				Hope this helps,
				
				Jack H. Smith

	
 9-Oct-85 14:38:23-MDT,2573;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 9 Oct 85 14:38:07-MDT
Received: from jpl-vlsi.arpa by AMSAA.ARPA id a013074; 9 Oct 85 15:54 EDT
Date:    Wed, 9 Oct 85 12:56:45 PDT
From:     dantas@JPL-VLSI.ARPA
Subject: please post on info-cpm
To:       info-cpm@AMSAA.ARPA

From:	VLSIDC::ST%"cpmlist@AMSAA.ARPA"  9-OCT-1985 12:16
To:	DANTAS
Subj:	[dantas:  EXOR S-100 SYSTEM INFO]

Received: from AMSAA by JPL-VLSI.ARPA with INTERNET ; Wed, 9 Oct 85 12:16:24 PDT
Date:     Wed, 9 Oct 85 14:38:06 EDT
From:     Dave Towson (info-cpm-request) <cpmlist@AMSAA.ARPA>
To:       dantas@jpl-vlsi.ARPA
Subject:  [dantas:  EXOR S-100 SYSTEM INFO]
 
Bob - The address "info-cpm-request@amsaa.arpa" is for matters dealing with
the operation of the mailing list (additions, deletions, changes, etc.).
Please send general articles such as this one to "info-cpm@amsaa.arpa" (i.e.,
leave off the "request").
 
 
Thanks,
 
Dave
 
 
----- Forwarded message # 1:
 
Received: from jpl-vlsi.arpa by AMSAA.ARPA id a023189; 3 Oct 85 7:47 EDT
Date:    Wed, 2 Oct 85 14:42:26 PDT
From:     dantas@JPL-VLSI.ARPA
Subject: EXOR S-100 SYSTEM INFO
To:       info-cpm-request@amsaa.arpa
 
I AM A MEMBER OF THE OKOK (OSBORNE KOMPUTER OWNERS KLUB), WHICH MEETS AT 
CALIF. INSTITUTE OF TECHNOLOGY IN PASADENA. THE CLUB AQUIRED AN EXOR S-100
COMPUTER SYSTEM TO DEDICATE IT FOR OPERATION OF A CLUB BULLETIN BOARD.
 
THIS SYSTEM OPERATES WITH CP/M 2.2, AND INCLUDES ONE 360K DS/DD FLOPPY
DRIVE AND ONE 5MEG HARD DISK DRIVE. THE SYSTEM WORKS FINE. BUT, UNFORTU-
NATELY CAME WITHOUT DOCUMENTATION. WE CAN SEND OR RECEIVE BUT HAVE NOT 
BEEN ABLE TO OPERATE IT IN DUPLEX MODE USING XMODEM.
 
IF ANYONE HAS A COPY OF THE DOCUMENTATION FOR THIS SYSTEM WE WOULD BE
HAPPY TO PAY FOR ANY CHARGES IN RECEIVING A COPY OF SAME.
 
BARING THIS WE WOULD LIKE TO REQUEST INFO ON PATCHING FOR BULLETIN
BOARD OPERATION ON XMODEM.
 
IF THIS IS IMPOSSIBLE THEN WE WOULD CONSIDER SELLING THE SYSTEM AND
INTERESTED PARTIES MAY CONTACT ME AT:
 
                        BOB DANTAS
                        1180 NO. HUDSON AVE.
                        PASADENA, CALIF. 91104
                          (818) 798-9903  LEAVE MESSAGE
 
            OR          % JET PROPULSION LABORATORY
                        4800 OAK GROVE DR.
                        MAIL SLOT T-1180
                        PASADENA, CALIF. 91109
                        
                        DANTAS@JPL-VLSI.ARPA
 
----- End of forwarded messages
10-Oct-85 06:14:34-MDT,1067;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 10 Oct 85 06:14:28-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id aa20215; 10 Oct 85 7:34 EDT
Received: from usenet by TGR.BRL.ARPA id a029617; 9 Oct 85 18:51 EDT
From: ir320 <ir320%sdcc6.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: A way to read 48 tpi disks on 96 tpi drives?
Message-ID: <2229@sdcc6.UUCP>
Date: 5 Oct 85 16:37:40 GMT
To:       info-cpm@AMSAA.ARPA

Hello netlanders,

I am getting a new computer and need to decide whether to get 96 tpi drives
or 48 tpi drives.  I know I get double the storage with 96 tpi, but I also
give up disk compatability with them don't I?  Is there a way I could
read/write a 48 tpi disks on a 96 tpi machine.  (The system is question
is the new SB180 system described in Byte.)  Can other systems write disks
for these drives?

John Antypas
UC San Diego

uucp: ...!{ ucbvax, decvax, ihnp4, noscvax, bang}!sdcsvax!sdcc6!ir320
arpa: ir320%sdcc6@sdcsvax.ARPA   sdcsvax!sdcc6!ir320@Berkeley.ARPA
 
10-Oct-85 06:17:09-MDT,767;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 10 Oct 85 06:17:02-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a020262; 10 Oct 85 7:35 EDT
Received: from usenet by TGR.BRL.ARPA id a002196; 9 Oct 85 21:52 EDT
From: branflick <dhb%mruxc.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: FTP for Tekelec
Message-ID: <571@mruxc.UUCP>
Date: 8 Oct 85 20:36:43 GMT
To:       info-cpm@AMSAA.ARPA

Subject: FTP for Tekelec
Newsgroups: net.micro.cpm

Is anyone on the net aware of a public domain FTP or Modem7 overlay
for the Tekelec TE707 Protocol Analyzer?  Please respond by Email as
I am sure most (all?) folks on the net have never heard of this
rather specialized piece of test gear.

Thanks,
Don
10-Oct-85 06:41:03-MDT,1295;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 10 Oct 85 06:40:56-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a020464; 10 Oct 85 7:41 EDT
Received: from mitre-bedford by SIMTEL20.ARPA with TCP; Wed 9 Oct 85 15:23:03-MDT
Date: Wednesday,  9 Oct 1985 12:48-EDT
From: tom@MITRE-BEDFORD.ARPA
To: info-cpm@SIMTEL20.ARPA
Cc: info-apple@BRL.ARPA, info-kermit@CU20B.ARPA, tom@MITRE-BEDFORD.ARPA
Subject: RESEND OF CPM KERMIT REQUEST

From: Trevor O. McCarthy:

	I sent a request three weeks ago  for information on kermit-80 for the
APPLE II series.  I cannot get it to run with an Applied Engineering Z80+ card
in slot #7 (using their CPM called "CPAM 4.1").  I have heard that some people
cannot get kermit-80 to run with Microsoft CP/M in any slot except 4 or 5.  Is
this true?  I can't change my slot assignments as all other slots have cards
or products already set up for them.

	I realise that someone may already have responded to my previous
message, but our ARPANET box was down, and I did not receive any mail. Anyone
who might have sent a response got it returned as undeliverable.  I would
appreciate a "resend" of any responses to my first message, as well as any
other replies, advice, or comments.

Thanks.
10-Oct-85 11:29:52-MDT,2133;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 10 Oct 85 11:29:32-MDT
Received: from usc-eclb.arpa by AMSAA.ARPA id a029168; 10 Oct 85 12:46 EDT
Date: 10 Oct 1985 09:49-PDT
Sender: STANLEY@USC-ECLB.ARPA
Subject: Re: A way to read 48 tpi disks on 96 tpi drives?
From: STANLEY@USC-ECLB.ARPA
To: ir320%sdcc6.uucp@BRL.ARPA
Cc: info-cpm@AMSAA.ARPA
Message-ID: <[USC-ECLB.ARPA]10-Oct-85 09:49:46.STANLEY>
In-Reply-To: <2229@sdcc6.UUCP>

	
    Received: from AMSAA.ARPA by USC-ECLB.ARPA; Thu 10 Oct 85 05:19:47-PDT
	      from brl-tgr.arpa by AMSAA.ARPA id aa20215; 10 Oct 85 7:34 EDT
	      from usenet by TGR.BRL.ARPA id a029617; 9 Oct 85 18:51 EDT
    Date: 5 Oct 85 16:37:40 GMT
    From: ir320 <ir320%sdcc6.uucp@BRL.ARPA>
    To:       info-cpm@AMSAA.ARPA
    Subject: A way to read 48 tpi disks on 96 tpi drives?
    Return-Path: <info-cpm-request@AMSAA>
    Message-ID: <2229@sdcc6.UUCP>
    Newsgroups: net.micro.cpm
    
    Hello netlanders,
    
    I am getting a new computer and need to decide whether to get 96 tpi drives
    or 48 tpi drives.  I know I get double the storage with 96 tpi, but I also
    give up disk compatability with them don't I?  Is there a way I could
    read/write a 48 tpi disks on a 96 tpi machine.  (The system is question
    is the new SB180 system described in Byte.)  Can other systems write disks
    for these drives?
    
    John Antypas
    UC San Diego
    
    uucp: ...!{ ucbvax, decvax, ihnp4, noscvax, bang}!sdcsvax!sdcc6!ir320
    arpa: ir320%sdcc6@sdcsvax.ARPA   sdcsvax!sdcc6!ir320@Berkeley.ARPA
     
    
	      --------------------
		
John,

You can read 48 tpi disks on 96 tpi drives by double-stepping the
head for each track; Heath H89's have been doing this for a long
time.  Writing in 48 tpi from a 96 tpi drive is another thing.
I've been told it can be done, and have seen it happen
occasionally on an IBM PC/AT, but my experience tells me it is a
very dicey business.  Reading can be done dependably, but not
writing.

                                ...Dick Stanley
10-Oct-85 13:57:39-MDT,1409;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 10 Oct 85 13:57:30-MDT
Received: from xerox.arpa by AMSAA.ARPA id a005151; 10 Oct 85 14:58 EDT
Received: from Aurora.ms by ArpaGateway.ms ; 10 OCT 85 11:59:51 PDT
Date: Thu, 10 Oct 85 11:35 EDT
From: Kushall.henr@XEROX.ARPA
Subject: Re: A way to read 48 tpi disks on 96 tpi drives?
In-reply-to: <2229@sdcc6.UUCP>
To: ir320 <ir320%sdcc6.uucp@BRL.ARPA>
cc: info-cpm@AMSAA.ARPA
Message-ID: <851010-115951-1795@Xerox>

I have a DEC Rainbow that uses DEC RX50 single sidded 96 tpi drives,
under MS-DOS I can read IBM PC single sidded 48 tpi disks.

There is also a program called Media Master that allows reading(and
writing) of many popular 96 & 48 tpi disks.

MM even allows the 96 tpi drive to format a disk to the popular 48 tpi
formats, Kaypro, IBM PC, Osborne.

One problem that can occur in writing is that the 96 tpi head width is
narrower than with a 48tpi drive (At least DEC claims it is) and a 48
tpi drive might have trouble reading a 48 tpi disk written with a 96 tpi
drive.
I have had very good results with this, but always use a 'new' disk to
avoid data residue that could be left from a 48 tpi write that may not
erase completly with a 96 tpi head.

To make a long story short, with the right software you can read the 48
tpi disks on the 96 tpi drives!

ED KUSHALL

10-Oct-85 14:42:32-MDT,719;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 10 Oct 85 14:42:17-MDT
Received: from cmu-cs-c.arpa by AMSAA.ARPA id a007593; 10 Oct 85 15:49 EDT
Received: ID <DDA@C.CS.CMU.EDU>; Thu 10 Oct 85 15:52:13-EDT
Date: Thu 10 Oct 85 15:52:08-EDT
From: Drew Anderson <Drew.Anderson@cmu-cs-c.ARPA>
Subject: 96/48 TPI compatibility
To: info-cpm@AMSAA.ARPA

I have been told that reading and writing of 48TPI format disks can
be done with double stepping (for reading) and bulk erased and reformatted
(both, not one or the other - for writing) disks.  If the disks are just
reformatted, there can be some confusion on the 48TPI drive's part.
				Drew Anderson
-------
11-Oct-85 06:02:52-MDT,932;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 11 Oct 85 06:02:43-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id ab11051; 11 Oct 85 7:13 EDT
Received: from usenet by TGR.BRL.ARPA id a018078; 10 Oct 85 22:34 EDT
From: u557593877ea <u557593877ea%ucdavis.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: C compiler info
Message-ID: <132@ucdavis.UUCP>
Date: 10 Oct 85 09:20:00 GMT
To:       info-cpm@AMSAA.ARPA

*** I DID REPLACE THIS LINE WITH MY MESSAGE ***


  I am interested in purchasing a C compiler and am consider the BDS compiler.
I am using a Z80 system with CP/M80.  I would appreciate any thoughts or
experiances on this or other low-priced compilers (under $200).
Thanks in advance...

            				Bruce Martin
ps  Please reply by E-mail!

(ARPA)   ucdavis!deneb!u557593877ea@ucb-vax.arpa
(UUCP)   ...!{ucbvax,dual}!ucdavis!deneb!u557593877ea
11-Oct-85 06:19:13-MDT,614;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 11 Oct 85 06:19:06-MDT
Received: from pica-lca.arpa by AMSAA.ARPA id a012082; 11 Oct 85 7:52 EDT
Date:     Fri, 11 Oct 85 7:48:36 EDT
From:     "Kenneth E. Van_Camp" (LCWSL) <kvancamp@PICA-LCA.ARPA>
To:       stanley@USC-ECLB.ARPA
cc:       info-cpm@AMSAA.ARPA
Subject:  read/write 48 tpi disks on 96 tpi drives

I disagree with Dick Stanley on writing 48 tpi disks on 96 tpi drives.
I've been reading & writing this way on my IBM PC AT for quite a while
with no complications (DOS 2.10).
		--Ken Van Camp
11-Oct-85 10:38:38-MDT,7426;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 11 Oct 85 10:38:12-MDT
Received: from lanl.arpa by AMSAA.ARPA id a021036; 11 Oct 85 11:54 EDT
Received: from a.ARPA by LANL.ARPA (4.12/4.7)
	id AA17687; Fri, 11 Oct 85 09:56:45 mdt
Received: by a.ARPA (4.12/4.7)
	id AA09030; Fri, 11 Oct 85 09:56:24 mdt
Date: Fri, 11 Oct 85 09:56:24 mdt
From: Richard Thomsen <rgt%a@LANL.ARPA>
Message-Id: <8510111556.AA09030@a.ARPA>
To: info-cpm@AMSAA.ARPA
Subject: Request for CP/M help on Find Next

	I need some help on using the CP/M Find First/Find Next commands.
I use the following routine to find the first file on the disk by using
the Find First CP/M command, then open the file and print the file name.
Then I close the file and use the same routine to find the next file.
On calling this routine, the ambigious file name is pointed to by reg HL,
and the last file found is pointed to by reg DE.  Reg A contains the value
zero on the first call, and 7 on successive calls.  I stepped through this
code with DDT, and everything seems proper, but the Find Next call always
returns with Reg A = 0FFH to indicate no files found.  But files exist!

	I got this code from _The CP/M Programmer's Handbook_ by Andy
Johnson-Laird, but it never finds the second or later files.  Another
version of code using this routine finds some, but not all, of the files
on the disk.  What am I doing wrong???

	I looked through the INSIDCPM.LBR, but they are not really doing
anything similar.  When I modify the program to not open the files that
were found, but just print the names, and also to not do the Find First
again, then it finds all the files.  But I need to open the files and
copy them, and this seems to screw up the Find Next!  Can anyone help?????


;++
;
;   TITLE:		GETNEXTF
;
;   TYPE:		Subroutine
;
;   ABSTRACT:
;
;	This subroutine gets the next file FCB from a possibly ambiguous file
;	name.  The actual FCB is stored in the destination FCB.
;
;
;   INPUTS:
;
;	Reg HL	--  Address of the possibly ambiguious file name FCB.
;	Reg DE	--  Address of FCB to contain the file name found
;	Reg A	--  File control byte.
;			Zero to return the first file name that matches
;			Non-zero to return the next file name that matches
;
;   OUTPUTS:
;
;	Carry	--  Exit status
;			Set	--  File not found
;			Clear	--  File name found and FCB set up
;
;   SIDE EFFECTS:
;
;	Address pointed to by reg DE is set to file name found.
;	DMA address is changed.
;
;   REGISTERS CHANGED:	A, B, C
;
;--
;
;   Define the data areas and values used by this subroutine
;
GNFFCBMOVSIZE	EQU	13		;Define size of FCB to be moved
GNFDIRBUF	DS	128		;Define buffer area for directory
;
;   Start of code  --  save the FCB addresses
;
GETNEXTF:
	PUSH	D		;Save destination FCB on stack
	PUSH	H		;Save source FCB on stack
	PUSH	PSW		;Save First/Next flag on stack
;
;   Set the DMA address to the directory buffer
;
	LXI	D,GNFDIRBUF	;Get address of directory buffer
	MVI	C,SETDMA	;Get code for set DMA
	CALL	BDOS		;Call BDOS to set the DMA address
;
;   DMA address set  --  see if first or next
;
	POP	PSW		;Restore First/Next flag
	ORA	A		;Check First/Next flag
	JNZ	GNFNEXT		;If next, use that call
;
;   Request is to get the first file name
;
	POP	D		;Get address of source file FCB for search
	PUSH	D		;And save it again
	MVI	C,SEARCHF	;Get code to search for first filename
	CALL	BDOS		;Call BDOS to perform search
	POP	H		;Restore address of source FCB
	POP	D		;Restore address of destination FCB
	CPI	0FFH		;See if file was found
	JZ	GNFFILENOTFND	;If not, then just exit with error
	JMP	GNFGETFCB	;Otherwise, get the FCB
;
;   Request is to get the next file name  --  search for next
;	First, the context of the file name must be restored by again
;	searching for the last one found.
;
GNFNEXT:
;
;   Request is to get the next file name  --  search for next
;	First, the context of the file name must be restored by again
;	searching for the last one found.
;
GNFNEXT:
	POP	H		;Recover address of source file name FCB
	POP	D		;Recover address of destination FCB
	PUSH	H		;Save them again, but in opposite order
	PUSH	D
	CALL	GNFZEROFILE	;Clear all but the name from the FCB
	POP	D		;Recover the destination FCB address
	PUSH	D		;And save it again
	MVI	C,SEARCHF	;Get code to search for the last file found
	CALL	BDOS		;And re-find that file

***   At this point, it finds the file again, as it should   ***

;
;   Now the FCB is set to what it was at the end of the last search.
;	Move the source FCB into the destination FCB and search for the next.
;
	POP	D		;Get the address of the destination FCB
	POP	H		;Get the address of the source FCB
	PUSH	D		;Save them again in the opposite order
	PUSH	H
	PUSH	D		;Save address of destination FCB again
	MVI	C,FCBSIZE	;Get the size of the FCB's
	CALL	MOVE		;Set the destination FCB to the source FCB
;
;   Now call the BDOS to search for the next occurance of the FCB
;
	POP	D		;Get address of destination FCB
	CALL	GNFZEROFILE	;And clear all but the name
	MVI	C,SEARCHN	;Get code to search for next file name
	CALL	BDOS		;Call the BDOS to do the search

***   At this point, it returns with Reg A = 0FFH, indicating no more files

	POP	H		;Restore the address of the source FCB
	POP	D		;Restore the address of the destination FCB
	CPI	0FFH		;See if file was found
	JZ	GNFFILENOTFND	;If not, then just exit with error
;
;
;   File was found  --  save the filename found in the save area for
;	next search
;
GNFGETFCB:
	PUSH	H		;Save the address of the source FCB
	PUSH	D		;Save the address of the destination FCB
	ADD	A		;Multiply return code by 32 to get offset
	ADD	A		;4
	ADD	A		;8
	ADD	A		;16
	ADD	A		;32
	LXI	H,GNFDIRBUF	;Get address of directory buffer
	MOV	E,A		;Put offset into reg E
	MVI	D,0		;Clear reg D to get 16-bit offset
	DAD	D		;Add to directory buffer
	POP	D		;Get address of destination FCB
	PUSH	D		;And save it again
	MVI	C,FCBSIZE	;Get size of entry to save
	CALL	MOVE		;Move name into save area
	POP	D		;Get the address of the destination FCB
	POP	H		;Get the address of the source FCB
	MOV	A,M		;Get the disk/user number from source
	STAX	D		;Store disk/user number in destination FCB
;
;   FCB now set to next disk  --  zero fill it for any disk commands
;
	PUSH	D		;Save the address of the destination FCB
	PUSH	H		;Save the address of the source FCB
	CALL	ZEROFCB		;Zero fill the FCB
	POP	H		;Restore the address of the source FCB
	POP	D		;Restore the address of the destination FCB
	XRA	A		;Clear carry to indicate success
	RET			;And return to caller
;
;   File not found  --  return error code to user
;
GNFFILENOTFND:
	STC			;Set carry to indicate error
	RET			;And return to caller
;
;   Clear the FCB except for the disk, file name, file type, and extent
;	Address of FCB is in reg DE.
;
GNFZEROFILE:
	LXI	H,13		;Bypass the file name and extent stored
	DAD	D		;Get the address of the part to clear
	MVI	C,36-13		;Get number of bytes to clear
GNFZEROFILELP:
	MVI	M,0		;Clear the byte
	INX	H		;Increment to next byte
	DCR	C		;Decrement count
	JNZ	GNFZEROFILELP	;Continue for all bytes
	RET			;Otherwise, return to caller
;

	Version 2.2 (I believe) of CP/M on a DEC Rainbow 100+.

						Richard Thomsen
						rgt@lanl
11-Oct-85 11:23:20-MDT,1507;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 11 Oct 85 11:23:12-MDT
Received: from usc-eclb.arpa by AMSAA.ARPA id a021995; 11 Oct 85 12:36 EDT
Date: 11 Oct 1985 09:38-PDT
Sender: STANLEY@USC-ECLB.ARPA
Subject: Re:  read/write 48 tpi disks on 96 tpi drives
From: STANLEY@USC-ECLB.ARPA
To: kvancamp@PICA-LCA.ARPA
Cc: stanley@USC-ECLB.ARPA, info-cpm@AMSAA.ARPA
Message-ID: <[USC-ECLB.ARPA]11-Oct-85 09:38:40.STANLEY>
In-Reply-To: The message of     Fri, 11 Oct 85 7:48:36 EDT from     Kenneth E. Van_Camp (LCWSL) <kvancamp@Pica-Lca.ARPA>

	
    Received: from PICA-LCA.ARPA by USC-ECLB.ARPA; Fri 11 Oct 85 04:56:14-PDT
    Date:     Fri, 11 Oct 85 7:48:36 EDT
    From:     Kenneth E. Van_Camp (LCWSL) <kvancamp@Pica-Lca.ARPA>
    To:       stanley@usc-eclb.arpa
    Cc:       info-cpm@amsaa.arpa
    Subject:  read/write 48 tpi disks on 96 tpi drives
    Return-Path: <kvancamp@Pica-Lca>
    
    I disagree with Dick Stanley on writing 48 tpi disks on 96 tpi drives.
    I've been reading & writing this way on my IBM PC AT for quite a while
    with no complications (DOS 2.10).
		    --Ken Van Camp
    
	      --------------------
		
Ken,

I'm glad to know it can be done with repeatability.  Any hints
you can offer on how to get the write part to work dependably
will be greatly appreciated.  My H89 won't do that at all, and
out PC/AT at the office bats no better than .400.

                                ...Dick
11-Oct-85 12:41:29-MDT,1598;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 11 Oct 85 12:41:17-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a024962; 11 Oct 85 14:15 EDT
Received: from hi-multics.arpa by AOS.BRL.ARPA id a019213; 11 Oct 85 14:06 EDT
Date:  Fri, 11 Oct 85 12:56 CDT
From:  "David S. Cargo" <Cargo@HI-MULTICS.ARPA>
Subject:  ? Info request of Baby Blue 2 & Earth TurboSlave
To:  info-cpm@BRL.ARPA
Message-ID:  <851011175646.693832@HI-MULTICS.ARPA>

I was hoping to add some hardware supported CP/M-80 capabilities to an
IBM-compatible computer.  I checked with two vendors who advertise in
BYTE (Oryx Systems Inc.  and Progressive Micro Distributors) to see if
they had the Xedex/Microlog Baby Blue II.  Both listed it, but neither
of them had it in stock.  Both said the vendor is "going bankrupt" and
it is therefore hard to get stock.  Question 1:  Is there some other
vendor that does have the Baby Blue II in stock?

A second alternative which now is appearing is the TurboSlave from Earth
computers.  This TurboSlave-PC has a Z80H, 128K of RAM, two RS232 ports,
and TurboDOS.  The price, $495 list, seems quite reasonable.  I just am
not sure I want to be the first person to try it.  Question 2:  Is there
anyone out there who has tried this board (and liked it)?

Please send your responses to Cargo at HI-Multics.  If I get any
responses I will summarize.  If I get other people asking for the
results of my query I will try to keep in touch.  $500 is not the kind
of money I would like to risk without taking a deeper look.
11-Oct-85 13:25:09-MDT,1131;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 11 Oct 85 13:25:03-MDT
Received: from rand-unix.arpa by AMSAA.ARPA id a025737; 11 Oct 85 14:47 EDT
Return-Path: <bridger@rand-unix.ARPA>
Received: by rand-unix.ARPA; Fri, 11 Oct 85 10:02:25 pdt
From: Bridger Mitchell <bridger@RAND-UNIX.ARPA>
Message-Id: <8510111702.AA00100@rand-unix.ARPA>
Date: 11 Oct 85 10:02:22 PDT (Fri)
To: Richard Thomsen <rgt%a@LANL.ARPA>
Cc: info-cpm@AMSAA.ARPA, bridger@RAND-UNIX.ARPA
Subject: Re: Request for CP/M help on Find Next
In-Reply-To: Your message of Fri, 11 Oct 85 09:56:24 mdt.
	     <8510111556.AA09030@a.ARPA>

The cp/m 2.2 search first/search next functions must be used
with NO INTERVENING bdos or bios file i/o calls.  Search-next
proceeds from internal bdos pointers and the bios's directory
buffer contents; a close-function, for example, will change
both and a subsequent search-next will be proceeding from
the end of the directory.  It is ok to use selected other (non-file i/o)
calls between search function calls, e.g. print-character.

--bridger mitchell



11-Oct-85 13:50:58-MDT,989;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 11 Oct 85 13:50:50-MDT
Received: from mitre.arpa by AMSAA.ARPA id a026115; 11 Oct 85 15:03 EDT
Received: by mitre.ARPA (4.12/4.7)
	id AA13975; Fri, 11 Oct 85 15:07:46 edt
Message-Id: <8510111907.AA13975@mitre.ARPA>
To: STANLEY@USC-ECLB.ARPA
Cc: kvancamp@PICA-LCA.ARPA, info-cpm@AMSAA.ARPA
Subject: Re: read/write 48 tpi disks on 96 tpi drives
In-Reply-To: Your message of 11 Oct 1985 09:38-PDT.
	     <[USC-ECLB.ARPA]11-Oct-85 09:38:40.STANLEY>
Date: 11 Oct 85 15:07:14 EDT (Fri)
From: Jeff Edelheit <edelheit@MITRE.ARPA>

For what it's worth, we were so concerned about read/write of 48 tpi
on our PC/AT we spent the extra $200+ and got the optional 48 tpi
second drive.

Dick, one thing to note in Ken's earlier note was that he said he
used 2.1 not 3.1.  If the 2.1 is a typo, then he is having much better
luck than anyonelse I know.

Jeff Edelheit
(edelheit@mitre)
12-Oct-85 05:43:47-MDT,861;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 12 Oct 85 05:43:42-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a002479; 12 Oct 85 7:18 EDT
Received: from usenet by TGR.BRL.ARPA id a008391; 11 Oct 85 18:40 EDT
From: Ted Medin <medin%noscvax.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: Looking for WATFOR compiler
Message-ID: <51@noscvax.UUCP>
Date: 10 Oct 85 19:58:52 GMT
To:       info-cpm@AMSAA.ARPA

In article <1953@brl-tgr.ARPA> Kushall.henr@XEROX.ARPA writes:
>WATFOR stands for WATerlooFORtran and is an interactive Fortran interputer.
>It was developed by Waterloo University in Canada.
>
>The first machine to use it was the Commadore 9000 (Super PET).
>I don't know if ever was made available for any other machines.
>
 I first used WATFOR on an IBM 360/65 in '66 or so.
12-Oct-85 06:01:52-MDT,1235;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 12 Oct 85 06:01:46-MDT
Received: from csnet-pdn-gw by AMSAA.ARPA id a002515; 12 Oct 85 7:20 EDT
Received: from umass-cs by csnet-relay.csnet id ae25906; 12 Oct 85 1:04 EDT
Date:     Fri, 11 Oct 85 10:11 EST
From:     "Robert (LISPer 68K) Heller" <HELLER%umass-cs.csnet@CSNET-RELAY.ARPA>
To:       Info-CPM@AMSAA.ARPA, Info-Micro@BRL.ARPA
Subject:  looking for a micro

I am looking for a cross-assambler for the 6502 type micro-processor
to run under CP/M-68K.  I doubt that such a program exists in a
ready-to-run form.  I will settle for such an assambler coded in C,
FORTRAN or Pascal in source form, which I could then translate (if
not C) and compile for my CP/M-68K system.  As another alternitive,
an assambler that runs on the VAX will be ok, if that is all that is
available.

			Robert Heller
			Visions Group
			COINS Dept.
			UMass/Amherst

			Electronic mail:
			UMass/RCF: 		HELLER
			UMass/ECS, 
			Smith College, 
			Hampshire College:	VAX1::HELLER
			Amherst College:	LISP
			UMass/Cyber:		HELLER@RCF.MAIL
			CSNet:			Heller@UMass-cs.CSNET
			ARPANet:  Heller%UMass-cs.CSNET@CSNet-Relay.ARPA
12-Oct-85 06:13:50-MDT,908;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 12 Oct 85 06:13:45-MDT
Received: from csnet-pdn-gw by AMSAA.ARPA id a002516; 12 Oct 85 7:20 EDT
Received: from umass-cs by csnet-relay.csnet id bm25906; 12 Oct 85 1:14 EDT
Date:     Sat, 12 Oct 85 00:11 EST
From:     One word is worth 10**-3 pictures <NEWMAN%umass-cs.csnet@CSNET-RELAY.ARPA>
To:       info-cpm@AMSAA.ARPA
Subject:  CP/M-68K compatibility


Do any of you folks know just what the degree of compatibility is
between CP/M-68K and CP/M-8{0,6}?  i (will) have CPM-68K and would
like toknow what CP/M programs i can run under it.  Are the call-outs
to BIOS done the same way?  i guess this request will also serve the
purpose of letting me find out what CP/M programs are available
in source form.

					-neville

				 Newman@UMass	(CSnet)
				 Newman%UMass@CSnet-Relay  (ARPAnet)
12-Oct-85 06:22:15-MDT,1253;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 12 Oct 85 06:22:09-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a002577; 12 Oct 85 7:24 EDT
Received: from usenet by TGR.BRL.ARPA id a014426; 12 Oct 85 5:41 EDT
From: Ted Medin <medin%noscvax.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: Looking for WATFOR compiler
Message-ID: <52@noscvax.UUCP>
Date: 10 Oct 85 20:04:10 GMT
To:       info-cpm@AMSAA.ARPA

In article <1980@brl-tgr.ARPA> young@UCI-ICSC.ARPA (Michal Young) writes:
>
>WATFOR was NOT first implemented on the SuperPET. It's immediate successor,
>WATFIV, is mentioned in the 1979 edition of the dragon book (Aho and
>Ullman), so WATFOR was around a long time before SuperPET. The version I am
>aware of was available on IBM mainframes and was not an interpreter;  it was
>a very fast compiler optimized for handling multiple compiles submitted in a
>batch.  It was specially designed for student use, concentrating on quick
>compile and good error checking rather than optimized object code.  

 I believe you are wrong about the interpreter part. But you are right about
all the rest. It was the best diagnostic compiler/interpreter I have ever
worked with.
12-Oct-85 06:34:27-MDT,1648;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 12 Oct 85 06:34:21-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id aa02577; 12 Oct 85 7:24 EDT
Received: from usenet by TGR.BRL.ARPA id a014467; 12 Oct 85 5:42 EDT
From: Bob Halloran <bobh%pedsgd.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: Backup on VCR
Message-ID: <308@pedsgd.UUCP>
Date: 9 Oct 85 12:16:47 GMT
To:       info-cpm@AMSAA.ARPA

Organization : Perkin-Elmer DSG, Tinton Falls NJ

In article <1945@brl-tgr.ARPA> JFORREST@SIMTEL20.ARPA (Jim Forrest) writes:
>A friend of mine would like to know if there is a RELATIVELY
>"easy and inexpensive" way to back up the hard disk on his Kaypro
>10 to his VCR.
>Appreciate response from anyone with expertise in this area.
>Jim

At one time, Corvus offered an option for their hard disk systems called
the 'Mirror', which allowed backing up hard disks to a VCR.  I don't
know whether it is still offered, what the cost is, or whether it is
available for a non-Corvus drive, but in principle it can be done.
Anyone else have more?

						Bob Halloran
						Sr MTS, Perkin-Elmer DSG
=============================================================================
UUCP: {decvax, ucbvax, most Action Central}!vax135\
		       	 {topaz, pesnta, princeton}!petsd!pedsgd!bobh 
ARPA: petsd!pedsgd!bobh@topaz
USPS: 106 Apple St M/S 305, Tinton Falls NJ 07724
DDD: (201) 758-7000
Disclaimer: My opinions are my own.
Quote: "It's Reagan's fault.  Everything's Reagan's fault.  Floods... 
   volcanoes...  herpes... Reagan's fault." -- Editor Overbeek, Bloom Beacon
12-Oct-85 07:08:45-MDT,1922;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 12 Oct 85 07:08:37-MDT
Received: from xerox.arpa by AMSAA.ARPA id a002654; 12 Oct 85 7:31 EDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 OCT 85 17:28:55 PDT
Sender: "Philip M. Burton.osbunorth"@XEROX.ARPA
Date: 11 Oct 85 14:26:53 PDT (Friday)
Subject: Re: 96/48 TPI compatibility - and comment on cheap drives for
 an AT
From: burton.osbunorth@XEROX.ARPA
To: info-cpm@AMSAA.ARPA
cc: info-ibmpc@USC-ISIB.ARPA, stanley@USC-ECLB.ARPA, 
    Drew.Anderson@cmu-cs-c.ARPA
In-Reply-to: Drew.Anderson%C.CS.CMU.EDU:ARPA:Xerox's message of
 11-October-85 (Friday) 0:57:58 PDT -
Reply-to: burton.osbunorth@XEROX.ARPA
Message-ID: <851011-172856-3130@Xerox>

The heads in a 96 tpi drive are *definitely* narrower than on a 48 tpi
drive.  I have successfully "read back" from a 96 tpi drive using a
Shugart SA 455.  I use this drive in my PC AT, and have no problems
reading from the 1.2 MB drive.  However, I have not been able to get
reliable readback using the Tandon or CDC drives IBM uses in PC's, or
with Teac drives.  It all depends on the head sensitivity, and also the
media quality.  

This approach is strictly for those who don't need backups.

For those who can roll their own, for less than 100 today, you can buy
a standard half-high SA 455.    Five bucks (see PC World back pages)
gets you a set of mounting rails.  You'll find a trace on the SA 455's
motherboard for  pin 34.  Cut this trace, and voila, you now have an
AT-compatible drive.  For drives without such a trace or jumper, just
cover pin 34 with some tape.  Install the drive as drive B, following
the AT's Installation Manual instructions, and you now have a two-floppy
system.  (Always convenient for floppy duplication.)  

At this price, there's no reason to take chances.

Phil Burton,
Xerox Corp. (ex-Shugart)
12-Oct-85 07:13:00-MDT,1377;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 12 Oct 85 07:12:55-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a002784; 12 Oct 85 7:39 EDT
Received: from usenet by TGR.BRL.ARPA id a017172; 12 Oct 85 6:47 EDT
From: cindy%ada-uts.uucp@BRL.ARPA
Newsgroups: net.micro.cpm
Subject: Re: Orphaned Response
Message-ID: <16800003@ada-uts.UUCP>
Date: 10 Oct 85 13:04:00 GMT
Nf-ID: #R:brl-tgr:-141400:ada-uts:16800003:177600:794
Nf-From: ada-uts!cindy    Oct 10 09:04:00 1985
To:       info-cpm@AMSAA.ARPA



    If anyone has an old (1.5 - 2 years) Morrow MD-11 that has troubles
with the hard disk, you might be interested in knowing that there is new
distribution software out that is more sofisticated about bad sectors on
the hard disk.  My troubles were caused by personal Pearl trying to write
to a bad sector.  When the service rep loaded with the new software, the
sectors were properly remapped, and the machine works like a charm!

    There is also an upgrade for some PAL chips, and my rep recommended a
new fan (the old models tend to over heat).

    So you might want to look into this before you run into these problems,
so that you don't loose any thing if it happens.  That's right, my backup
is worthless...

NET: {harpo, allegro, bellcore, ihnp4}!inmet!ada-uts!cindy



----------
12-Oct-85 07:30:41-MDT,1417;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 12 Oct 85 07:30:35-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a002892; 12 Oct 85 7:47 EDT
Received: from mitre-bedford by SIMTEL20.ARPA with TCP; Fri 11 Oct 85 17:17:11-MDT
Date: Friday, 11 Oct 1985 18:35-EDT
From: tom@MITRE-BEDFORD.ARPA
To: info-cpm@SIMTEL20.ARPA
Cc: info-apple@BRL.ARPA, info-kermit@CU20B.ARPA
Subject: RESEND OF CPM KERMIT AND XMODEM REQUEST

From: Trevor O. McCarthy:

	I sent a request out recently for information on kermit-80 for the
APPLE II series.  I cannot get it to run with an Applied Engineering Z80+ card
in slot #7 (using their CPM called "CPAM 4.1").  I have heard that some people
cannot get kermit-80 to run with Microsoft CP/M in any slot except 4 or 5.  Is
this true?  I can't change my slot assignments as all other slots have cards
or products already set up for them.

	I would also appreciate any information on any public domain xmodem
packages available for the Apple II, that will tranfer CPM files.


	I realise that someone may already have responded to my previous
message, but our ARPANET box was down, and I did not receive any mail; anyone
who might have sent a response got it returned as undeliverable.  I would
appreciate a "resend" of any responses to my first message, as well as any
other replies, advice, or comments.

Thanks.
12-Oct-85 09:12:06-MDT,1379;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 12 Oct 85 09:11:57-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a000385; 12 Oct 85 10:49 EDT
Received: from simtel20.arpa by AOS.BRL.ARPA id a026267; 12 Oct 85 10:45 EDT
Date: Sat, 12 Oct 1985  08:44 MDT
Message-ID: <KPETERSEN.12150535467.BABYL@SIMTEL20.ARPA>
Sender: KPETERSEN@SIMTEL20.ARPA
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
To:   Info-Cpm@BRL.ARPA
Cc:   Info-Micro@BRL.ARPA, Telecom@MIT-MC.ARPA, Info-Modem7@SIMTEL20.ARPA
Subject: USR Courier 2400 bps modem for $389

Anyone interested in purchasing a US Robotics Courier 2400 bps modem
will want to check out the deal offered by Microcomputer Concepts.
Their price is $389 plus shipping.

Microcomputer Concepts
5291 Clark Circle
Westminster, CA  92683
Phone: 800-772-3914 (voice)
       714-896-0775 (modem RBBS 300-1200-2400 bps)

Contact: Gary Johnson

Disclaimer: I have no connection with Microcomputer Concepts except as
a satisfied customer (I bought a Courier 2400 two weeks ago.  It
arrived within a week of placing my phone COD order which was shipped
via regular UPS).

--Keith Petersen
Arpa:  W8SDZ@SIMTEL20.ARPA
uucp:  ...!seismo!SIMTEL20.ARPA!W8SDZ
uucp:  ...!{decvax,unc,hao,cbosgd,seismo,aplvax,uci}!brl-bmd!w8sdz
uucp:  ...!{ihnp4!cbosgd,cmcl2!esquire}!brl-bmd!w8sdz
15-Oct-85 05:31:52-MDT,1221;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 15 Oct 85 05:31:45-MDT
Received: from xerox.arpa by AMSAA.ARPA id a009274; 15 Oct 85 6:57 EDT
Received: from CheninBlanc.ms by ArpaGateway.ms ; 14 OCT 85 08:21:46 PDT
Date: Mon, 14 Oct 85 08:21 PDT
From: VOORHEIS.ES@XEROX.ARPA
Subject: Re: A way to read 48 tpi disks on 96 tpi drives?
In-reply-to: <851010-115951-1795@Xerox>
To: ir320 <ir320%sdcc6.uucp@BRL.ARPA>
cc: info-cpm@AMSAA.ARPA
Message-ID: <851014-082146-4135@Xerox>

We recently purchased a Compaq AT compatable and were having trouble
formating diskettes.  The unit has one 96tpi and one 48tpi drives.
After talking with the service people at the store, here is the summary:

-a 96 tpi drive can read and write* 48 tpi format.
-a 48 tpi drive can read diskettes formated to 48 tpi by a 96 tpi drive.
-use High Density media when writing with 96 tpi drives.
-use double density media when writing with 48 tpi drives.

*We were told that 96 tpi drives heads are narrower and that the write
current is different than 48 tpi drives.  Therefore, 48 tpi drives
cannot write on HD media and 96 tpi drive cannot write on 2D (double
density media).
15-Oct-85 06:01:41-MDT,1130;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 15 Oct 85 06:01:33-MDT
Received: from xerox.arpa by AMSAA.ARPA id a009284; 15 Oct 85 6:57 EDT
Received: from PinotNoir.ms by ArpaGateway.ms ; 14 OCT 85 11:47:09 PDT
Date: 14 Oct 85 11:44 PDT
From: Ghenis.pasa@XEROX.ARPA
Subject: Re: C compiler info
In-reply-to: u557593877ea <u557593877ea%ucdavis.uucp@BRL.ARPA>'s message
 of 10 Oct 85 09:20:00 GMT
To: u557593877ea%ucdavis.uucp@BRL.ARPA
cc: info-cpm@AMSAA.ARPA
Message-ID: <851014-114709-4438@Xerox>

Think twice about getting BDS C: it may compile very fast, but it is
non-standard enough to make porting a pain. If you have no intention of
ever recompiling your code on another system that's fine, otherwise...

More standard low price compilers for CP/M are C/80 with Mathpak
(produces very efficient code) and Q/C (comes with source code!) among
others. MIX C was been prematurely anounced at $39.95 three months ago
and they aren't shipping yet (hmm...).

Check the C compiler reviews in Dr. Dobbs, Byte and Computer Language
for some very complete info.
15-Oct-85 06:05:44-MDT,731;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 15 Oct 85 06:05:38-MDT
Received: from xerox.arpa by AMSAA.ARPA id a009285; 15 Oct 85 6:58 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 OCT 85 20:15:53 PDT
Date: 14 Oct 85 20:15:49 PDT (Monday)
From: pencin.dlos@XEROX.ARPA
Subject: Re: SCAN -- a program to look at text and squeezed files
In-reply-to: <512@ecsvax.UUCP>
To: Ted Emigh <emigh%ecsvax.uucp@BRL.ARPA>
cc: info-cpm@AMSAA.ARPA
Message-ID: <851014-201553-4865@Xerox>

I'm interested in your program, it looks like a fine extension to
bishow...please let me know how I can get a copy of the program to post
on a CPM BBS that I run here in Dallas.

Russ
15-Oct-85 06:43:21-MDT,753;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 15 Oct 85 06:43:15-MDT
Received: from ames-vmsb.arpa by AMSAA.ARPA id a009732; 15 Oct 85 7:07 EDT
Date: 11 Oct 85 16:46:00 PST
From: nep.pgelhausen@AMES-VMSB.ARPA
Subject: --- re: find first/next ---
To: info-cpm@AMSAA.ARPA
Reply-To: nep.pgelhausen@AMES-VMSB.ARPA

I tried sending this directly, but the mailer had some problems
w/ what I thought the address was, so re. the find/next problem:

If you can print the names properly, I would suggest COPYING
each name as find next finds them, then after all names have
been found use your list of file names to open each of them.

			-Richard Hartman
			max.hartman@ames-vmsb
------
------
15-Oct-85 06:44:22-MDT,1032;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 15 Oct 85 06:44:17-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a009773; 15 Oct 85 7:09 EDT
Received: from usenet by TGR.BRL.ARPA id a007812; 13 Oct 85 2:53 EDT
From: Tom Almy <toma%tekchips.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: Looking for WATFOR compiler
Message-ID: <283@tekchips.UUCP>
Date: 10 Oct 85 14:31:32 GMT
To:       info-cpm@AMSAA.ARPA

In article <1953@brl-tgr.ARPA> Kushall.henr@XEROX.ARPA writes:
>WATFOR stands for WATerlooFORtran and is an interactive Fortran interputer.
>It was developed by Waterloo University in Canada.
>
>The first machine to use it was the Commadore 9000 (Super PET).
>I don't know if ever was made available for any other machines.
>
>Ed

Gee, I used WATFOR in 1968 on an IBM 360.  They (Univ. of Waterloo) also
released in about that time frame WATFIV (WATerloo Fortran IV) and a 
terrific Assembler.  I was very impressed with their compilers.

Tom
15-Oct-85 07:11:27-MDT,1562;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 15 Oct 85 07:11:21-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id ab09773; 15 Oct 85 7:09 EDT
Received: from usenet by TGR.BRL.ARPA id a013920; 13 Oct 85 14:51 EDT
From: Chuck McManis <cem%intelca.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: A way to read 48 tpi disks on 96 tpi drives?
Message-ID: <120@intelca.UUCP>
Date: 11 Oct 85 15:21:24 GMT
To:       info-cpm@AMSAA.ARPA

> I am getting a new computer and need to decide whether to get 96 tpi drives
> or 48 tpi drives.  I know I get double the storage with 96 tpi, but I also
> give up disk compatability with them don't I?  Is there a way I could
> read/write a 48 tpi disks on a 96 tpi machine.  (The system is question
> is the new SB180 system described in Byte.)  Can other systems write disks
> for these drives?

The Ampro can read 48TPI disks on 96TPI drives, and since Joe Wright wrote
the BIOS for the SB180 and is/was heavily involved in the Ampro software I
suspect the SB180 will also support this capability. Another solution is 
to spend the $20 for a single sided 48TPI drive and use it as a spare for
compatibility purposes. 

--Chuck

-- 
                                            - - - D I S C L A I M E R - - - 
{ihnp4,fortune}!dual\                     All opinions expressed herein are my
        {qantel,idi}-> !intelca!cem       own and not those of my employer, my
 {ucbvax,hao}!hplabs/                     friends, or my avocado plant. :-}
15-Oct-85 07:13:17-MDT,2136;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 15 Oct 85 07:13:10-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id aa09773; 15 Oct 85 7:09 EDT
Received: from usenet by TGR.BRL.ARPA id a009858; 13 Oct 85 5:58 EDT
From: Bob Halloran <bobh%pedsgd.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: A way to read 48 tpi disks on 96 tpi drives?
Message-ID: <312@pedsgd.UUCP>
Date: 11 Oct 85 12:14:20 GMT
To:       info-cpm@AMSAA.ARPA

Organization : Perkin-Elmer DSG, Tinton Falls NJ

In article <2229@sdcc6.UUCP> ir320@sdcc6.UUCP (ir320) writes:
>I am getting a new computer and need to decide whether to get 96 tpi drives
>or 48 tpi drives.  I know I get double the storage with 96 tpi, but I also
>give up disk compatability with them don't I?  Is there a way I could
>read/write a 48 tpi disks on a 96 tpi machine.  (The system is question
>is the new SB180 system described in Byte.)  Can other systems write disks
>for these drives?

A 96tpi drive CAN read disks written on a 48tpi drive; the second part
of the construction article for that same SB180 implies as much.  The 
BIOS needs some extra code to realize it must double-step for these
disk formats.  The major problem as I understand it is that in writing, 
the 96tpi drive lays down a narrower 'track' than the 48tpi drive (makes 
sense), which may either get lost against a previously written 'wide' 
track if the disk has been used before in a 48tpi drive, or simply be 
too narrow for the 48tpi drive's head to get a useful signal from.

Hope this helps. 

						Bob Halloran
						Sr MTS, Perkin-Elmer DSG
=============================================================================
UUCP: {decvax, ucbvax, most Action Central}!vax135\
		       	 {topaz, pesnta, princeton}!petsd!pedsgd!bobh 
ARPA: petsd!pedsgd!bobh@topaz
USPS: 106 Apple St M/S 305, Tinton Falls NJ 07724
DDD: (201) 758-7000
Disclaimer: My opinions are my own.
Quote: "It's Reagan's fault.  Everything's Reagan's fault.  Floods... 
   volcanoes...  herpes... Reagan's fault." -- Editor Overbeek, Bloom Beacon
15-Oct-85 07:39:36-MDT,1769;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 15 Oct 85 07:39:30-MDT
Received: from csnet-pdn-gw by AMSAA.ARPA id a010285; 15 Oct 85 7:27 EDT
Received: from gte-labs by csnet-relay.csnet id ab10495; 15 Oct 85 5:24 EDT
Received: by bunny.UUCP (4.12/5.03) id AA15284; Mon, 14 Oct 85 14:06:16 edt
	for 
Date: Mon, 14 Oct 85 14:06:16 edt
From: Alan Gunderson <asg0%gte-labs.csnet@CSNET-RELAY.ARPA>
To: info-cpm@amsaa.csnet
Subject: SB180 & Tandon half-height drives

You can get one Tandon half-height drive to work with a SB180 system
by jumpering it so that the drive is selected all the time.  It should
also be jumpered so that the 'Motor On' function is NOT controlled by
the drive selection, i.e., the seperate 'Motor On' signal line is
used.  Having the drive selected all the time precludes the use of
multiple drives.  There appears to be a strange timing incompatability
between the disk controller on the SB180 and the Tandon drives.  I
think I may have to peel the drive select lines coming out of the disk
controller off and run them into some special circuitry and then into
the Tandon drives to be able to use multiple drives.  For now, I at
least can boot ZRDOS and make back ups.  Be informed that the Tandon
drives don't support the READY line.  You must jumper the JP6
selection on the SB180.  I installed a switch on this jumper, so that
I can get to the SB180 monitor.  When JP6 is wired permanently, the
monitor thinks the drive is always ready, and thus tries to autoboot.
You can fix this be reburning a new monitor PROM, but I haven't gotten
around to this yet.


====Alan Gunderson
uucp:  ...!seismo!harvard!bunny!asg0
csnet: asg0%gte-labs.csnet@csnet-relay.arpa

15-Oct-85 07:47:58-MDT,2521;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 15 Oct 85 07:47:49-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a010315; 15 Oct 85 7:27 EDT
Received: from simtel20.arpa by AOS.BRL.ARPA id a002049; 15 Oct 85 0:03 EDT
Date: Mon, 14 Oct 1985  22:02 MDT
Message-ID: <KPETERSEN.12151204977.BABYL@SIMTEL20.ARPA>
Sender: KPETERSEN@SIMTEL20.ARPA
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
To:   Info-Cpm@BRL.ARPA
Cc:   Info-Modem7@SIMTEL20.ARPA
Subject: Easier FTPing of files from SIMTEL20

Thanks to Frank Wancho <WANCHO@SIMTEL20> we now have system-wide
defines (logical names) of the MICRO:<CPM.*> directories.  What this
means is that you no longer have to deal with long names like
MICRO:<CPM.MEX>MEX114.LBR.  Just tell ftp to get MEX:MEX114.LBR (in
this example).  The latest list of directory names follows.  Simply
add a colon after the name of your choice and then the file name.

22RSX         COMND         GENASM        NEWS          SYSUTL
6502          CPM3          GENCOM        NSTAR         T20-SQUSQ
AMETHYST      CPM86         GENDOC        OSBORN        TELEFONE
APPLE         CPMLIB        HAMMING       PACKET        TERM
ASMUTL        CPR86         HAMRADIO      PASCAL        TOPS-20
ATARI         CUG           HDUTL         PCDOS         TRS-80
AZTEC-C       DBASEII       HEATH         PCPURSUIT     TURBODOS
BASIC         DEBUG         HELP          PILOT80       TURBOPAS
BDOS          DIRUTL        HEX           PLOT33        TXTUTL
BDSC-1        DISASM        IBM-PC        PPSPEL        VAXVMS
BDSC-2        DISKPLOT      IMP           PUBKEY        VDOEDIT
BDSC-3        DSKBUF        INSIDCPM      PUBPATCH      VOICE
BDSC-4        DSKUTL        KAYPRO        RBBS          WSTAR
BSTAM         EDITC80       LIST          RBBS4         XCCP
BYE3          EDITOR        MACLIB        RCPM          XLISP
BYE5          EMX           MATH          ROS           YAM
BYT85FEB      EPSON         MBBS          SMALLC21      Z3LIBS
BYT85JAN      EZCPR         MEMTEST       SORT          Z3NEW
C80           FAST2         MEX           SPELL         Z8EDEBUG
CATLOG        FIDO          MICNET        SQU-PORT      ZCPR
CB80          FILCPY        MISC          SQUSQ         ZCPR2
CBIOS         FILUTL        MODEM         STARTER-KIT   ZCPR3
CCP           FINANCE       MODEM2        SUBMIT
COBOL         FORTH-83      MODEM7        SYSLIB
COMMODORE     FORTRAN       MSOFT         SYSLIB3

--Keith
15-Oct-85 08:46:51-MDT,1821;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 15 Oct 85 08:46:42-MDT
Received: from pica-lca.arpa by AMSAA.ARPA id a013066; 15 Oct 85 8:42 EDT
Date:     Tue, 15 Oct 85 8:40:12 EDT
From:     "Kenneth E. Van_Camp" (LCWSL) <kvancamp@PICA-LCA.ARPA>
To:       info-cpm@AMSAA.ARPA
Subject:  Reading & writing 48 tpi on 96 tpi drives

Please note that I DID say I'm using DOS 2.10 to write my 48 tpi disks on
the 96 tpi drives. I can't say what happens after the disks have been on
the shelf for a year because I've only had my AT a few months. I have
definitely been able to read these 48 tpi disks on my XT, though, so I am
NOT just reading them on the same kind of drive I'm writing on. (The XT has
standard 48 tpi drives.) As far as brands are concerned, my 96 tpi drive
is the standard one that comes with all AT's from IBM. I would estimate
that I've read at least 15 diskettes on a 48 tpi drive that were created on
the 96 tpi drive. That may not be enough to reach any definite conclusions,
but so far success has been 100%. I should also mention that about half of
these diskettes were 48 tpi, the other half 96 tpi formatted to 48. So the
statement that you shouldn't use the 96 tpi disks at 48 format doesn't seem
to hold, either.
	I can't remember if there's any difference between the way DOS 2.10
and DOS 3.0 write 48 tpi diskettes, because I've always used strictly DOS
2.10. Can someone help me out on that? If there is, then this may be the
source of the problem for you 3.0 people. Using the HIDE/UNHIDE utilities
in the public domain you should be able to rename you hidden dos files and
maintain both operating systems on your hard disk. Or come to think of it,
I guess all you'd need is both versions of FORMAT.
		--Ken Van Camp
15-Oct-85 08:54:28-MDT,2245;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 15 Oct 85 08:54:19-MDT
Received: from usc-eclb.arpa by AMSAA.ARPA id a013744; 15 Oct 85 8:57 EDT
Date: 15 Oct 1985 06:00-PDT
Sender: STANLEY@USC-ECLB.ARPA
Subject: Spurious Lockups
From: STANLEY@USC-ECLB.ARPA
To: info-cpm@AMSAA.ARPA, heath-people@MIT-MC.ARPA
Message-ID: <[USC-ECLB.ARPA]15-Oct-85 06:00:46.STANLEY>

Netlandians:

I need some bright suggestions.  I have recently installed the
CDR Super-RAM in my Heath H89.  This gizmo contains a megabyte of
RAM (41256's) that can be accessed as a RAM disk, with 64K of the
1024K serving as the computer's main memory.  The RAM install
program allows you to boot from the RAM disk, by partitioning it
into two logical disks, A: and B:, and "sliding" the physical
disks up two logical slots.  So, when I turn on the H89, I boot
from physical and logical disk A:, but after I run the INSRAM
installation program, physical disk A: is now logical disk C:.

OK, that is how it is set up.  However, since the installation,
the system has had a large number of spurious responses.
Sometimes the keyboard will lock up for no apparent reason.
Sometimes, I will return to the H89 to find input showing on the
command line that I did not type.  Other times, the terminal will
just go crazy, ringing the bell and filling the screen with
garbage.  These responses also seem to have the effect of
inserting spurious characters into files on the RAM drives.

I have checked everything thoroughly, and all seems OK.  The
terminal section passes all the standard tests.  The response
seems independent of terminal speed, or whether I am running with
the RAM disk as A:, or as some higher disk.  It also happens when
running from floppies, without having installed the RAM disk!

The H89 is connected to a power conditioner, so I don't think
power glitches are a problem.  But when these gremlins take over,
the only way to recover is to reset and re-boot the H89.  The RAM
disk files are not lost, but as noted above, they are often
trashed.

I would welcome any suggestions to help solve this problem.

                                ...Dick Stanley

stanley@eclb

15-Oct-85 09:25:37-MDT,1633;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 15 Oct 85 09:25:30-MDT
Received: from lanl.arpa by AMSAA.ARPA id a014712; 15 Oct 85 9:11 EDT
Received: from a.ARPA by LANL.ARPA (4.12/4.7)
	id AA10713; Tue, 15 Oct 85 07:15:17 mdt
Received: by a.ARPA (4.12/4.7)
	id AA17359; Tue, 15 Oct 85 07:14:51 mdt
Date: Tue, 15 Oct 85 07:14:51 mdt
From: Richard Thomsen <rgt%a@LANL.ARPA>
Message-Id: <8510151314.AA17359@a.ARPA>
To: info-cpm@AMSAA.ARPA
Subject: Re: Need help on CP/M Find First/Find Next


	I am forwarding this answer to the net.

From GRUPP@MIT-MC.ARPA Sat Oct 12 00:56:38 1985
Received: from LANL.ARPA (ccf-gateway.ARPA) by a.ARPA (4.12/4.7)
	id AA27011; Sat, 12 Oct 85 00:56:34 mdt
Received: from MIT-MC.ARPA (mit-mc.arpa.ARPA) by LANL.ARPA (4.12/4.7)
	id AA23343; Sat, 12 Oct 85 00:56:36 mdt
Date: Sat, 12 Oct 85 02:57:52 EDT
From: Paul R. Grupp <GRUPP@MIT-MC.ARPA>
Subject:  Request for CP/M help on Find Next
To: rgt%a@LANL.ARPA
In-Reply-To: Msg of Fri 11 Oct 85 09:56:24 mdt from Richard Thomsen <rgt%a at LANL.ARPA>
Message-Id: <[MIT-MC.ARPA].677315.851012.GRUPP>
Status: R

Richard,

    Try this.  When you find the first file with search for first
save the name away in a buffer.  Then when you are ready to search
for next, do a search for first again with the UNambigious filename
you stored away (this will get you back to where you left off).
THEN do your search for next with your ambigious file spec.  Of course
you will need to save any filename found now for the next search for
next.

-Paul


	End of forwarded message.
15-Oct-85 09:34:16-MDT,3260;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 15 Oct 85 09:33:56-MDT
Received: from lanl.arpa by AMSAA.ARPA id a015510; 15 Oct 85 9:22 EDT
Received: from a.ARPA by LANL.ARPA (4.12/4.7)
	id AA10800; Tue, 15 Oct 85 07:26:18 mdt
Received: by a.ARPA (4.12/4.7)
	id AA17567; Tue, 15 Oct 85 07:25:52 mdt
Date: Tue, 15 Oct 85 07:25:52 mdt
From: Richard Thomsen <rgt%a@LANL.ARPA>
Message-Id: <8510151325.AA17567@a.ARPA>
To: grupp@MIT-MC.ARPA
Subject: Help on CP/M Find First/Find Next
Cc: info-cpm@AMSAA.ARPA

Paul,

	Thanks for your help, but that is what I tried.  Please look at my
code, which I got from _The CP/M Programmer's Handbook_ by Andy Johnson-Laird.
I have the address of the ambigious filename in reg HL, and the unambigious
file name in reg DE.  I search for the "destination" FCB (the one found last
time), then search for the next one using the ambigious FCB, which I have
copied into the "destination" FCB.  In one case, it never finds the second
filename.  In another case, it finds 17 out of 25 filenames.  I can see no
patterns in what it does and does not find.

	My code is not exactly like that in the book,
but the idea is the same.

	Excerpted from my subroutine to get first/next filename.
The entire subroutine was posted last time.  This is just the part that
finds the NEXT filename.  The DMA buffer has been set up already.
The "destination" FCB is the one that was filled last time from the one
found.  The file name in that FCB has been opened and closed, using this
FCB.  The "source" FCB is the ambigious file name used in the last
"find first/find next" call to this subroutine.

;
;   Request is to get the next file name  --  search for next
;	First, the context of the file name must be restored by again
;	searching for the last one found.
;
GNFNEXT:
	POP	H		;Recover address of source file name FCB
	POP	D		;Recover address of destination FCB
	PUSH	H		;Save them again, but in opposite order
	PUSH	D
	CALL	GNFZEROFILE	;Clear all but the name from the FCB
	POP	D		;Recover the destination FCB address
	PUSH	D		;And save it again
	MVI	C,SEARCHF	;Get code to search for the last file found
	CALL	BDOS		;And re-find that file
;
;   Now the FCB is set to what it was at the end of the last search.
;	Move the source FCB into the destination FCB and search for the next.
;
	POP	D		;Get the address of the destination FCB
	POP	H		;Get the address of the source FCB
	PUSH	D		;Save them again in the opposite order
	PUSH	H
	PUSH	D		;Save address of destination FCB again
	MVI	C,FCBSIZE	;Get the size of the FCB's
	CALL	MOVE		;Set the destination FCB to the source FCB
;
;   Now call the BDOS to search for the next occurance of the FCB
;
	POP	D		;Get address of destination FCB
	CALL	GNFZEROFILE	;And clear all but the name
	MVI	C,SEARCHN	;Get code to search for next file name
	CALL	BDOS		;Call the BDOS to do the search
	POP	H		;Restore the address of the source FCB
	POP	D		;Restore the address of the destination FCB
	CPI	0FFH		;See if file was found
	JZ	GNFFILENOTFND	;If not, then just exit with error
;
;   File was found  --  save the filename found in the save area for
;	next search
;
GNFGETFCB:

15-Oct-85 10:21:09-MDT,979;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 15 Oct 85 10:21:02-MDT
Received: from mit-multics.arpa by AMSAA.ARPA id a017518; 15 Oct 85 10:14 EDT
Date:  Sun, 13 Oct 85 15:17 EDT
From:  AALevy@MIT-MULTICS.ARPA
Subject:  NULU12 disaster
To:  info-cpm@AMSAA.ARPA
Message-ID:  <851013191732.921339@MIT-MULTICS.ARPA>

I have a friend who happily used NULU12 to squeeze files on his
molecular super micro-x running a hard-disk with 8k blocks.  Apparently
he squeezed nsweep2 was used, and put in a library using nulu.  Two
problems, when he tries to view certain members or extract , he gets a
disk error, other members have some parts of their file name
disappearing.  Any suggestions to

A- recovery

or

B- versions that won't do this in the future.

Thanks, Allan

Also NSWP2 gave disk errors when the files were being squeezed (some of
them it just did not squeeze) when a mass sqeeze was used on NSWP2.
15-Oct-85 10:30:52-MDT,473;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 15 Oct 85 10:30:47-MDT
Received: from mit-multics.arpa by AMSAA.ARPA id a017543; 15 Oct 85 10:15 EDT
Date:  Sun, 13 Oct 85 15:20 EDT
From:  AALevy@MIT-MULTICS.ARPA
Subject:  Bye for Molecular Supermicr-X
To:  info-cpm@AMSAA.ARPA
Message-ID:  <851013192014.570314@MIT-MULTICS.ARPA>

Does anyone know of a Bye type program for a molecular super micro-x

Thanks, Allan
16-Oct-85 06:06:34-MDT,767;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 16 Oct 85 06:06:26-MDT
Received: from edwards-2060.arpa by AMSAA.ARPA id a001854; 16 Oct 85 7:33 EDT
Date: Tue 15 Oct 85 16:36:29-PDT
From: D-ROGERS@EDWARDS-2060.ARPA
Subject: cp/m documentation
To: info-dec-micro@SU-SCORE.ARPA
cc: info-cpm@AMSAA.ARPA

I purchased a Rainbow from DEC bundled with MBASIC and MULTIPLAN.  It came
with an impressive collection of manuals, but the impression faded soon,
when i discovered that there was no documentation on ddt, ddt86, or the 
details of writing in asm or asm86.  Are other Rainbow owners in the same
fix?  Can anyone point me to where i can fill in the missing documentation?
Thanks...		d. e. rogers
-------
16-Oct-85 06:27:36-MDT,1696;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 16 Oct 85 06:27:27-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a001894; 16 Oct 85 7:35 EDT
Received: from mit-mc.arpa by AOS.BRL.ARPA id ac12582; 16 Oct 85 2:00 EDT
Received: from MIT-EECS by MIT-MC.ARPA via Chaosnet; 13 OCT 85  16:42:58 EDT
Date: Sun 13 Oct 85 16:39:15-EDT
From: Andrew Moore <T.MOORE%MIT-EECS@MIT-MC.ARPA>
Subject: Problem with card slots & CP/M
To: info-apple@MIT-MC.ARPA, info-cpm@MIT-MC.ARPA


   I am trying to use an SSM serial interface card (note:  NOT the Super-Serial
card!) on an Apple II+ CP/M system with a Diablo 630 printer.  The card works
fine from Applesoft BASIC but if I try to go into CP/M, the system freezes up.
I have tried two CP/M cards, and the same problem occurs with both.  I have
tried both MicroSoft 60k CP/M and the 10MB Sider hard drive's 60k CP/M, and
the problem occurs with both CP/Ms here too.  My slots are configured as
follows:

0  16k expansion card
1  SSM serial interface card (to Diablo 630)
2  Apple-Cat II/212a modem
3  Viewmax-80 80col/lowercase
4  MicroSoft-Compatible CP/M card
5  EMPTY
6  Floppy controller
7  10MB Sider controller

   If I put the serial card in slot #5, I can use CP/M but it will not send
anything to the printer -- I suppose this is because CP/M expects the printer
to be interfaced to slot #1.  Is there any way around this problem, or does
anyone know any possible configuration that will let me use the Sider's CP/M
with a Diablo 630 on the SSM serial card?

-drew
 MOORE%MIT-EECS@MIT-MC.ARPA
 (please send replies directly;  I am not on info-cpm/-apple)
-------

16-Oct-85 06:42:08-MDT,631;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 16 Oct 85 06:42:03-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id ab01894; 16 Oct 85 7:35 EDT
Received: from xerox.arpa by AOS.BRL.ARPA id a012252; 16 Oct 85 1:31 EDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 OCT 85 13:54:28 PDT
Sender: "Leslie A. Kanno.OsbuSouth"@XEROX.ARPA
Date: 14 Oct 85 10:17:27 PDT (Monday)
Subject: Please add me to list
From: kanno.OsbuSouth@XEROX.ARPA
To: INFO-CPM@BRL-AOS.ARPA
cc: kanno.OsbuSouth@XEROX.ARPA
Message-ID: <851014-135428-4572@Xerox>



Thanks,

  Kanno.es@Xerox.arpa
16-Oct-85 06:53:09-MDT,2678;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 16 Oct 85 06:52:58-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a002005; 16 Oct 85 7:40 EDT
Received: from usenet by TGR.BRL.ARPA id a021793; 15 Oct 85 19:52 EDT
From: Eric Hestenes <hestenes%sdcsla.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: Classified ads
Message-ID: <996@sdcsla.UUCP>
Date: 7 Oct 85 17:29:50 GMT
To:       info-cpm@AMSAA.ARPA

> Eric - Since I started the discussion, I'd like to reply to your comments.

> information between interested parties.  I, for one, would like to know that
> if you buy a product from XYZ for either employment/research or 
> personal-related work, the kind of support you might get from the vendor.

I don't know what you mean here. 

> The ARPANET was not intended for use as an advertising medium for either
> commercial concerns or individuals to sell goods and/or services.  

I agree. However, part of the problems being encountered stem from the
fact that arpanet people want to share *extensively* with non-arpa people.
This implicitly implies an exchange of information that goes beyond purely
military activities. If you throw out many ads, you're throwing the clothes
out with the bathwater. Essentially, I agree that ads, under the proclaimed
goals of arpa, are against the rules. However, banning some ads will
certainly harm the goals of arpa, namely, increased, effective interaction
with the defense support community ( note, not only the dod itself, since if 
this were the goal they could cut the lines or use the darpa ( not arpa )
network. )

When I post an ad to a non-arpa newsgroup, is it my fault that someone
automatically forwards it to every defense site? No, as long as i am not
violating the rules of the local newsgroup, i can't be to blame. Rather,
it is the group of arpa folks who crave and subcribe to this newsgroup that
have asked for extra baloney. 

Of course, when the ads violate non-arpa standards, then the poster is to
blame. But that debate also belongs to the users of the lan, not the
incidental subscribers from the arpanet. 

I hope i haven't infuriated to many generals by writing this stuff, since
it is fairly political by nature. Can we agree to disagree? I still think that
no matter what, one must abide by the rules of the community of users, and
that there is a place for compromise for mutually benefitting parties. 



------------
Eric Hestenes
arpanet: hestenes@nprdc.ARPA
other: ucbvax!sdcsvax!sdcsla!hestenes or hestenes@sdcsla.UUCP
[ all opinions are my own and are not related to those of my employer ]
16-Oct-85 07:08:30-MDT,1771;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 16 Oct 85 07:08:19-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a002181; 16 Oct 85 7:42 EDT
Received: from usenet by TGR.BRL.ARPA id a027804; 16 Oct 85 2:43 EDT
From: Chuck Forsberg WA7KGX <caf%omen.uucp@BRL.ARPA>
Newsgroups: net.micro,net.micro.pc,net.micro.cpm
Subject: Latest YMODEM.DOC revision available
Message-ID: <244@omen.UUCP>
Date: 14 Oct 85 10:33:43 GMT
Xref: seismo net.micro:13057 net.micro.pc:6039 net.micro.cpm:5130
To:       info-cpm@AMSAA.ARPA

A revision of YMODEM.DOC, describing the XMODEM, XMODEM/CRC, and
YMODEM protocol is now available on Telegodzilla (503-621-3746)
as well as via uucp using the L.sys entry below.  The files in
omen!/usr/spool/uucppublic  are:

    110    625   4050 Makefile		how to nroff or troff it
    464   2602  15763 mdmenh.mi		troff/nroff source files
     32    109    865 vers.mi		troff/nroff source files
    404   2595  16388 xmcrc.mi		troff/nroff source files
     85    229  31137 ymodem.dQc
   1650   7222  49446 ymodem.doc
     15     88    372 ymodem.tmi	troff/nroff source files
    383   1762  10934 yproto.mm		troff/nroff source files

The YMODEM extensions include 1k packets for greater throughput,
batch file transfers to minimize keystrokes and user time,
exact file length, and file modification date.

-- 
  Chuck Forsberg WA7KGX   ...!tektronix!reed!omen!caf   CIS:70715,131
Omen Technology Inc     17505-V NW Sauvie Island Road Portland OR 97231
Home of Professional-YAM, the most powerful COMM program for the IBM PC
Voice: 503-621-3406     Modem: 503-621-3746 (Hit CR's for speed detect)
omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp
16-Oct-85 07:35:54-MDT,1290;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 16 Oct 85 07:35:40-MDT
Received: from usc-isid.arpa by AMSAA.ARPA id a003235; 16 Oct 85 8:14 EDT
Date: 16 Oct 1985 02:09-EDT
Sender: ABN.ISCAMS@USC-ISID.ARPA
Subject: Re: SCAN -- a program to look at text and squeezed files
From: ABN.ISCAMS@USC-ISID.ARPA
To: pencin.dlos@XEROX.ARPA
Cc: emigh%ecsvax.uucp@BRL.ARPA, info-cpm@AMSAA.ARPA
Message-ID: <[USC-ISID.ARPA]16-Oct-85 02:09:20.ABN.ISCAMS>
In-Reply-To: <851014-201553-4865@Xerox>

Russ (et al),
(Russ responded to Ted Emigh about SCAN, suggesting it might be a good
extension to bishow.}
I did a hack and put assembler routines for Unsqueezing squeezed text
files into BISHOW.  Works just fine, but .. since you're having to
buffer text (to permit paging back and forth), it's aggravating to
wait not only while your system reads in from disk a new buffer full,
but then the Unsqueezing too.  Since I used two different buffer sizes
(one for reads, one for the unsqueezed text), it got a little strange.
Worked .. but as I said, aggravating.

If you wanna see how I did it, yell, and I'll (painstakingly) upload
the source code where you can FTP it.

Regards,
David Kirschbaum
Toad Hall
ABN.ISCAMS@USC-ISID.ARPA
16-Oct-85 09:09:23-MDT,2731;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 16 Oct 85 09:09:15-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a007944; 16 Oct 85 10:25 EDT
Date: Wed, 16 Oct 1985  08:29 MDT
Message-ID: <WANCHO.12151581188.BABYL@SIMTEL20.ARPA>
From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
To:   Eric Hestenes <hestenes%sdcsla.uucp@BRL.ARPA>
Cc:   INFO-CPM@AMSAA.ARPA
Subject: Classified ads

Eric,

    When I post an ad to a non-arpa newsgroup, is it my fault that
    someone automatically forwards it to every defense site?  No, as
    long as i am not violating the rules of the local newsgroup, i
    can't be to blame.  Rather, it is the group of arpa folks who
    crave and subcribe to this newsgroup that have asked for extra
    baloney.

You have it backwards.  For the record, I started INFO-CPM at MIT-MC
as an ARPANET mailing list spinoff of INFO-MICRO on 29 August 1980.
The uucp newgroup was subsequently created to subscribe to this list.
The same sequence occurred earlier when I resurrected INFO-MICRO after
it had become dormant for about a year.  There are several other
newsgroups with similar ARPANET origins, such as HUMAN-NETS, the first
digest format mailing list and SF-LOVERS.

One of the reasons that several mailing lists went to digest format
was to filter out such for-sale messages to save the list from being
disbanded.  Over the years, both INFO-CPM and INFO-MICRO lists have
been occassionally hit with for-sale messages, with the subsequent
flurry of messages reminding people of the restrictions imposed on the
ARPA community and redirecting the poster to the apparently little
known and used for-sale or wanted newsgroups.  At times, there is even
a suggestion that these lists be converted to digest format to filter
for-sale messsages.  Unfortunately, no one wants to volunteer as the
burnout rate for moderators of high-volume lists is also high.

You ask if we can agree to disagree.  The answer is no.  For sale
message to newsgroups such as INFO-CPM and INFO-MICRO will not be
tolerated.  For-sale messages leaking into what is now called DDN
(Defense Data Network) is quite a serious matter.  There is mention of
it in netiquette, which every potential poster to a newsgroup should
read.  The consequences on the DDN side if users from a particular
host do not observe this restriction is to pull their connection from
the net.  This has never actually happened, but it has come close on
more than one occassion in the early years.  The consequences on the
uucp side is to drop the gateway.  We do not wish to do that.  But if
you insist on ignoring our restrictions, we have no choice.

--Frank
16-Oct-85 10:22:14-MDT,1025;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 16 Oct 85 10:22:08-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a010758; 16 Oct 85 11:41 EDT
Date: Wed 16 Oct 85 09:40:33-MDT
From: Rick Conn <RCONN@SIMTEL20.ARPA>
Subject: Re: Help on CP/M Find First/Find Next
To: rgt%a@LANL.ARPA
cc: grupp@MIT-MC.ARPA, info-cpm@AMSAA.ARPA
In-Reply-To: <8510151325.AA17567@a.ARPA>
Message-ID: <12151594197.9.RCONN@SIMTEL20.ARPA>

SYSLIB contains a set of routines for directory accessing, and the
source code may help in answering your questions.  The DIRF routine
inits a buffer area, loads a disk directory, selects a set of files
from the loaded dir, selects user areas, packs the dir, and alphabetizes.
DIRFS does the same, but provides information on file sizes as well (and runs slower).
There are also DIRLOAD and DIRSLOAD.

	The source code is in the SDIR.MAC modules of SYSLIB3: on SIMTEL20.
I think there are several SDIR*.MAC modules there.

		Rick
-------
16-Oct-85 11:42:02-MDT,1217;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 16 Oct 85 11:41:56-MDT
Received: from xerox.arpa by AMSAA.ARPA id a013762; 16 Oct 85 12:57 EDT
Received: from CheninBlanc.ms by ArpaGateway.ms ; 16 OCT 85 09:58:02 PDT
Date: 16 Oct 85 08:59:00 PDT (Wednesday)
From: Stiles.es@XEROX.ARPA
Subject: Re: SCAN -- a program to look at text and squeezed files
In-reply-to: <851014-201553-4865@Xerox>
To: pencin.dlos@XEROX.ARPA
cc: Ted Emigh <emigh%ecsvax.uucp@BRL.ARPA>, info-cpm@AMSAA.ARPA
Message-ID: <851016-095802-6133@Xerox>

Hi Russ,

This is not specifically in reply to your message above, but prompted by
it and today's reply by David Kirschbaum.  When I visited you this
summer you mentioned that you had a friend up at PARC who has an account
on the VAX that can get to SIMTEL20.  I have such an account also but
haven't been able to get it to work.  Could you give me his name and net
address?  I'd like to contact him and have him forward to me the Chat
typescript from such a session so I can see what I am doing wrong.  Then
possibly I can 'share the load' in getting new programs for [ISIS]<CPM>
and your RCPM (as my time allows!).

Bill~
17-Oct-85 06:08:43-MDT,981;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 17 Oct 85 06:08:36-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a024145; 17 Oct 85 7:32 EDT
Received: from usenet by TGR.BRL.ARPA id a017784; 16 Oct 85 19:06 EDT
From: "Michael S. Romaniw" <msr%bunker.uucp@BRL.ARPA>
Newsgroups: net.micro,net.micro.cpm
Subject: Need help with Rainbow printer(LA50)
Message-ID: <1016@bunker.UUCP>
Date: 16 Oct 85 03:00:04 GMT
Xref: seismo net.micro:13074 net.micro.cpm:5138
To:       info-cpm@AMSAA.ARPA


	I just got my hands on a DEC Rainbow running CPM, (no doc of course),
and am running into trouble getting the printer (LA50) to work.  It seems to
be overflowing its' buffer at 4800 baud...dropping it to 1200 just delays the
data overrun.  Does the Rainbow use XON/XOFF ??? or does it use the BUSY/OUT?
What about parity ????  Can anyone help ?

					Thanks,
					Mike Romaniw
					Bunker Ramo
					...decvax!bunker!msr
17-Oct-85 13:31:05-MDT,5563;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 17 Oct 85 13:30:47-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a006673; 17 Oct 85 14:31 EDT
Received: from usenet by TGR.BRL.ARPA id a005408; 17 Oct 85 14:13 EDT
From: "R.Thomas" <rbt%sftig.uucp@BRL.ARPA>
Newsgroups: net.micro.apple,net.micro.cpm,net.micro
Subject: (Apple CPM) AE Ramworks and PCPI Applicard questions
Message-ID: <609@sftig.UUCP>
Date: 16 Oct 85 21:33:44 GMT
Xref: seismo net.micro.apple:2395 net.micro.cpm:5139 net.micro:13085
To:       info-cpm@AMSAA.ARPA

The following is the text of a letter I sent today to Applied Engineering
about their Ramworks ramdisk driver for the PCPI Applicard CPM card for the
Apple II series.

My question for the net is --

Does anybody have a fix for these problems?

Also, if Steven N. Hirsch is on the net (He appears to have been the author
of the driver in question...)  would he please get in touch with me.

Please respond by E-mail, if possible.

Thanks in advance

Rick Thomas
{ihnp4, akgua, most other backbone sites}!attunix!rbt
(201) 522-6062


------------------------------------------------------------------
						

						October 16, 1985

Applied Engineering
PO Box 798
Carrollton Texas 75006


Dear Sirs:

I recently bought a copy of your ramdrive device driver for the Applied
Engineering Ramworks(tm) board and the PCPI Applicard(tm).

I have noticed a couple of problems with it that I hope you will
correct in later releases.  I would also appreciate it if you could
send me an appropriate patch for the release I have.

I am using it on an 'enhanced' Apple IIe, with an Applicard in slot 4,
an Apple Super-Serial card in slot 1 for my serial printer, an Apple
Duo-Disk in slot 6, and an Apple extended 80 column color card in
the Auxiliary slot.  I was told over the phone by your tech support
people before I bought it, that the software would work with the
Apple color card just as well as with the Ramworks card, though the
resulting ramdrive would be small.  In fact it does seem to work
quite well.  There is enough room in the ramdrive for a copy of
Turbo Pascal, PIP, and a few other useful utilities, and even a small
amount of scratch space left over.  I have a small "SUBMIT" file on
my boot disk that loads up the ramdrive with the things I want on it
at system startup time.  The feature of configuring the ramdrive as
disk A: is really very nice! 

The first problem is really quite trivial, and I would not mention
it at all, except that I am already writing to you about the second
problem.  The first problem is that the "R" and "W" that are supposed
to flash in the lower right corner of the screen, appear as mousetext
instead of letters on my enhanced IIe.  As I say, not a big problem,
but something worth noting for future releases.  Personally, I would
have preferred to hear the speaker grumble a little bit when the
ramdrive was working, instead of having one character of my screen be
taken away from me, but that is a matter of preference.  (After all,
real disk drives make noise when they are doing something, why not the
ramdrive too?)

The second problem is somewhat more serious.  The README.WS file that
comes on the same disk with the software warns of a potential conflict
between the PCPI BUFFER.DVR printer driver and the ramdrive software
over control of the first (in my case the only) bank of auxiliary
memory.  It says to "Be aware of this, and install accordingly."  But
it does not say what installing accordingly means.  Is there an
alternate printer driver that does not use the aux memory?
Or is there a patch to BUFFER.DVR to prevent it from using the
aux memory.  BUFFER.DVR works just fine without the auxiliary
memory on machines without the extended 80-column card.  It buffers in
the leftover part of main memory.  So it presumably could be patched 
to ignore aux memory altogether, but the README.WS file does not
give a clue as to how to accomplish this.

With these questions in my mind, I said to myself, "nothing ventured,
nothing gained." and decided to try it anyway.  To my surprise, it
seemed to work!  I put things in the ramdrive, and got them back
intact.  I queued up several small files to the printer and could
still use the ramdrive.  The queued files printed fine.  They were
obviously not being overwritten by the stuff I put in the ramdrive. 
So, OK, BUFFER.DVR must be using the leftover main memory first, and
only going to the aux memory as a last resort.  "Well," said I,
"lets really load it up and watch it rip!"  So I queued up a very
large file to print that should have filled up the available main
memory and sloshed over into the aux memory, then tried some ramdrive
activity.  Still OK!  "Better and better!" said I, feeling really
fine.  But still, that warning in the README.WS file must have meant
something!  So I queued up a second copy of the same print file and
about half way through it, the entire system hung.  Everything stopped
at once.  I had to cold boot to clear it up.

So the conclusion is that if I am careful not to fill up the printer
buffer too full, I can use it the way I have it configured.  But it
would be awfully nice to have some kind of patch that would keep it
from hanging if I get careless and queue up too much printer output.
Also, the README.WS file should be more explicit on the subject of
"installing accordingly".



			Sincerely,

			Rick Thomas
17-Oct-85 13:36:46-MDT,1997;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 17 Oct 85 13:36:28-MDT
Received: from lanl.arpa by AMSAA.ARPA id a007454; 17 Oct 85 14:55 EDT
Received: from a.ARPA by LANL.ARPA (4.12/4.7)
	id AA09496; Thu, 17 Oct 85 12:37:30 mdt
Received: by a.ARPA (4.12/4.7)
	id AA03554; Thu, 17 Oct 85 11:31:28 mdt
Date: Thu, 17 Oct 85 11:31:28 mdt
From: Richard Thomsen <rgt%a@LANL.ARPA>
Message-Id: <8510171731.AA03554@a.ARPA>
To: d-rogers@EDWARDS-2060.ARPA
Subject: DEC Rainbow Manuals
Cc: info-cpm@AMSAA.ARPA

D. E. Rogers:

	DEC sells three manual sets for the Rainbow, each one is
(I believe) about $75.  I do not know why DEC does not include any
data with its systems unless you buy the manual set, but that is what
they do.  If you want to know ANYTHING about the operating systems
(other than the most basic stuff), you must buy the manual set.
I could not even use MS-DOS DEBUG without the manual set.

	The manuals are as follows:

		CP/M Technical Documentation Manual
		MS-DOS Technical Documentation Manual
		Rainbow 100B/100+ Technical Documentation Manual.

	The CP/M and MS-DOS manuals contain data on the operating systems,
and the other one is for the hardware itself.  The hardware manual includes
complete specs on the boards, connectors, memory map, etc.  The operating
system manuals give only memory maps for the operating system itself and
the interrupts they use, plus BIOS listings, etc.

	All are from DECDIRECT.  When I bought mine, they sent the manuals
for the 100A, not the 100B.  It took me quite a while to get the right ones.
I hope that they have that corrected by now.  If not, and you get the
wrong manuals, you only have 30 days to correct the mistake.

						Richard Thomsen
						rgt@lanl

	CP/M is a trademark of DRI
	MS-DOS is a trademark of Microsoft
	DEC, Rainbow 100A, 100B, 100+, and DECDIRECT are trademarks of DEC
	(Digital Equipment Corporation)
	Did I forget any?
18-Oct-85 06:39:37-MDT,1263;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 18 Oct 85 06:39:29-MDT
Received: from usc-isi.arpa by AMSAA.ARPA id a015561; 18 Oct 85 7:48 EDT
Date: 17 Oct 1985 21:08:46 EDT
From: DKREBILL@USC-ISI.ARPA
Subject: Wide Bandwidth/SLow speed{Exchanges
To:   info-cpm@AMSAA.ARPA
cc:   krebill@ARDC.ARPA

There have been a number of indications that all of the "free"
packets we netland{ans enjoy a la  bulletins
boards and ftps on the DDN will begin to bill charged-
back in something akin to real money. In preparation for that day,
and reflecting on my own less than urgent needs, has anything
been done to set up a mechanism for gettting 9 track tape copies
of the archives for PD S/W residing now on SIMTEL 20? For example,
is it now possible for me to send you a tape to get a "bulk copy
of most of the CPM or MS-DOS PD S for a minimal
administrative cost. While I am more immedia{ely interested for
purposes of obtaining same for users around campus, this sort of 
administative setup could satisfy other users and cutdown on FTP
packets substanially
When/if we really sta{t paying for  net traffic, I would guess
every effort to reduce on-line transfers would help....Da{
send{

-------
18-Oct-85 06:51:48-MDT,751;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 18 Oct 85 06:51:43-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a015631; 18 Oct 85 7:52 EDT
Received: from usenet by TGR.BRL.ARPA id a019969; 18 Oct 85 7:42 EDT
From: "Mark D. Falleroni" <mdf%trwrba.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: TURBO Question
Message-ID: <1637@trwrba.UUCP>
Date: 16 Oct 85 15:41:11 GMT
To:       info-cpm@AMSAA.ARPA


I'm trying to write a terminal program in TURBO.  Would someone 
tell me how to write a function that tells me when a character
is ready for input at the serial port of my CP/M machine????????
Thanks in advance for any help given.
		Mark Falleroni
		TRW
		Ogden, Utah
		<mdf>
18-Oct-85 12:46:34-MDT,989;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 18 Oct 85 12:46:27-MDT
Received: from mitre.arpa by AMSAA.ARPA id a024356; 18 Oct 85 14:08 EDT
Received: by mitre.ARPA (4.12/4.7)
	id AA03847; Fri, 18 Oct 85 14:13:30 edt
Message-Id: <8510181813.AA03847@mitre.ARPA>
To: "Kenneth E. Van_Camp" (LCWSL) <kvancamp@PICA-LCA.ARPA>
Cc: info-cpm@AMSAA.ARPA
Subject: Re: Reading & writing 48 tpi on 96 tpi drives
In-Reply-To: Your message of Tue, 15 Oct 85 8:40:12 EDT.
	     <8510181614.AA03125@mitre.ARPA>
Date: 18 Oct 85 14:12:56 EDT (Fri)
From: Jeff Edelheit <edelheit@MITRE.ARPA>

Ken - DOS 3.0/1 gives you the capability of formatting the 1.2 mb 
floppies on the 96tpi drive.  I don't believe that 2.1 supports that.

Considering the advantages of 3.0/1, I am somewhat suprised that
you are still using 2.1; especially on an AT.  I guess, though,
if you are happy with 2.1, there's no motivation to move-up.

Regards,

Jeff
19-Oct-85 09:32:32-MDT,1774;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Sat 19 Oct 85 09:32:25-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a001386; 19 Oct 85 10:58 EDT
Received: from usenet by TGR.BRL.ARPA id a011048; 19 Oct 85 11:00 EDT
From: pete%stc.uucp@BRL.ARPA
Newsgroups: net.micro.cpm
Subject: Where's the DMA Address?
Message-ID: <647@stc-b.stc.UUCP>
Date: 18 Oct 85 09:00:24 GMT
Xpath: stc stc-b stc-b stc-a
To:       info-cpm@AMSAA.ARPA


        Put briefly, I need to know how I can find the address of
        the current DMA area.

        Expansion:

        I'm running CP/M-80 Ver. 2.2. This enables me to set the DMA to
        anywhere I like; fair enough, there's a system call for it
        (26). But I can't find any way to set it back to what it was
        before, only the default at 80H.

        The reason I want to do this is that I'm designing a print
        spooler for my home system, a Gemini Multi-Board system,
        using an area in my RAM-disk for the spool file(s) and
        interrupts from a real-time clock to drive the despooling.
        Now, sooner or later my interrupt routine is going to want
        to read a sector from the RAM-disk when an application
        program has set the DMA address to somewhere other than the
        default area. If I restore the DMA address from that used by
        the despooler to the default - Blooey!!

        I can't find this data in my Digital Research manuals.

        Any help would be very welcome.

        If there is a lot of interest, I'll summarise to the net.

        Many thanks,
-- 
	Peter Kendell <pete@stc.UUCP>

	...mcvax!ukc!stc!pete

	'Only too far is far enough'
19-Oct-85 10:06:04-MDT,4279;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Sat 19 Oct 85 10:05:51-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a001447; 19 Oct 85 11:32 EDT
Received: from usenet by TGR.BRL.ARPA id a012170; 19 Oct 85 11:29 EDT
From: Eric Hestenes <hestenes%sdcsla.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: Classified ads
Message-ID: <1009@sdcsla.UUCP>
Date: 18 Oct 85 10:50:05 GMT
To:       info-cpm@AMSAA.ARPA

> --Frank says:
> 
> You have it backwards.  For the record, I started INFO-CPM at MIT-MC

> The same sequence occurred earlier when I resurrected INFO-MICRO after
> it had become dormant for about a year.  There are several other
> newsgroups with similar ARPANET origins, such as HUMAN-NETS, the first

I don't debate the order of events or event the role of the arpanet in 
fostering interest in various areas. You win that battle, though you don't win
them all in this area. 


> You ask if we can agree to disagree.  The answer is no.  For sale
> message to newsgroups such as INFO-CPM and INFO-MICRO will not be
> tolerated.  For-sale messages leaking into what is now called DDN
> (Defense Data Network) is quite a serious matter.  There is mention of

Why is it serious? Or rather, to whom is it serious to?

> it in netiquette, which every potential poster to a newsgroup should

Which i have read. 


> read.  The consequences on the DDN side if users from a particular
> host do not observe this restriction is to pull their connection from
> the net.  This has never actually happened, but it has come close on
> more than one occassion in the early years.  The consequences on the
> uucp side is to drop the gateway.  We do not wish to do that.  But if
> you insist on ignoring our restrictions, we have no choice.


I'd really like to hear a definition of net.micro.cpm that doesn't include
INFO-CPM. Are they one and the same group? Or are they different?
This issue goes beyond ad postings. The meat of it is, who calls the shots.
Does arpanet call the shots in usenet newsgroups? It appears so. If this is
the case, then let's just admit it once and for all.


Also, if this group is gateway'd to arpa, why isn't it called fa.info-cpm
rather than net.micro.cpm. Or even better, mail.info-cpm?
On usenet, this *is* the ettiquite. Or am I mistaken?

Overall, you totally miss the point. 

If a usenet newsgroup allows ads ( e.g. na.for-sale ) and those ads
are forwarded all over the DDN, who ( as a result ) deserves to be yanked off
of the net - the poster or the person who made the connection? 
It's a chicken or the egg problem, except among certain net historians and
finger pointers. 

-------
The answer obviously lies in negotiation and observing the tendancies that
will best help *both* newsgroups. 
-------

And it is here that I think we should
agree to disagree on . I think limited ads are useful, even for arpanet 
types, and certainly for non-arpa types. This is a *philosophical* stance, not a
*political* one.  Politically, you guys win. After all, Mr DoD pays my paycheck
also.  ( After i've paid him, of course ). Believe me, I know the rules and try 
to abide by them.

But the issue over whether there is a legitimate advantage in terms of
communication in using one forum versus the other is just not settled!
You don't decide what is best, you explore and find out! Just like with
television and radio, it is not possible to foresee all the ways a medium
may be used. I personally would like to see many, many more people use
networks like this if only for the reason that it makes certain kinds of
activities easier to accomplish. And I don't think that this can happen
without cost, but what other major technologies didn't get started in the
defense sector?  I am pro-technology and pro-effective communication,
not anti-arpa. Peek at the larger issue, rather than the most obvious
( and redundant ) interpretation.


But aside from the noise here, this discussion was 
old  before it started. I give up.
No hard feelings, I hope.




eric

---
I'm thankful to say that these opinions have nothing to do with those of my
employer. They are mine only.
19-Oct-85 11:11:41-MDT,3506;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Sat 19 Oct 85 11:11:32-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a001590; 19 Oct 85 12:43 EDT
Received: from simtel20.arpa by AOS.BRL.ARPA id a006274; 19 Oct 85 12:45 EDT
Date: Tuesday, 15 October 1985  05:59-MDT
Message-ID: <KPETERSEN.12152392293.BABYL@SIMTEL20.ARPA>
Sender: James Potter <jp%a@LANL.ARPA>
From: James Potter <jp%a@LANL.ARPA>
Subject:   Software Tools in Turbo Pascal for CP/M-86 and MSDOS
ReSent-From: KPETERSEN@SIMTEL20.ARPA
ReSent-To: Info-Cpm@BRL.ARPA
ReSent-Date: Sat 19 Oct 1985 10:44-MDT

I have posted the files for Software Tools in Pascal (Turbo Pascal
version) to SIMTEL20 as:

Filename			Type	 Bytes	 CRC

Directory MICRO:<CPM.TURBOPAS>
TRBTOL86.LBR.1			BINARY	 70784  0559H

This library contains the source from the book "Software Tools in
Pascal" by B.W. Kernighan and P.J. Plauger, Addison-Wesley.  It has
been adapted for Turbo Pascal.  Accepts redirection, but not pipes.
The version using TURBO is fast enough to make this a useful set of
tools for file manipulation.

The primitives in this version are basically the UCSD Pascal versions
presented in the book, with modifications for Turbo Pascal.

This version has been modified for use under Turbo Pascal v. 3.0 under
CP/M-86.  There are no system dependent statements in the code to the
best of my knowledge, so it should work under MS-DOS as well.

The original version (typed in by Bill McGee) was set up for CP/M-80
and used the CHAIN capability of Turbo Pascal.  I have eliminated that
feature in favor of using INCLUDE files.  There is not enough memory
available in a CP/M-80 system for this version, but one could modify
the include file list to eliminate unwanted features or to make more
than one version, (e.g. break out EDIT, FORMAT, and DEFINE).

There was really only one change required to the McGee's original to
get it to work with version 3.0.  A readln(TRM) had to be added in the
subroutine GETKBD.  The change to CP/M-86 required replacing all calls
to the procedure BDOS(0,0) with HALT.  This change works with the
CP/M-80 version of Turbo Pascal v. 3.0 as well.  Thus, as anyone can
see, all of the hard work was done by Bill.

Please note that this is copyrighted software.  Right has been granted
to freely distribute or duplicate this software, providing
distribution or duplication is not for profit or other commercial gain
and that the copyright notice within remains intact.

I originally received these from a telephone BBS without the copyright
notices.  I spoke with Brian Kernighan and he indicated that, as far
as he was concerned, there was no problem if suitable copyright
notices were included.  The notice I used is the same as the one on
the Chris Lewis version already archived.  I also spoke to Bill McGee,
the originator of these files.  He said that he did little more than
type them in and felt no proprietary interest of his was involved.
Likewise, I only made a few simple modifications to get the programs
working under CP/M-86.

There has been a lot of interest in the Software Tools for Turbo
Pascal on the nets, judging by all the mail I have received recently.
I particularly like the translit program.  And I want to use the macro
expansion program on a project I'm working on.

I find the editor not too useful and the archive program ditto.

Jim Potter  jp@lanl.arpa
19-Oct-85 13:31:36-MDT,4912;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Sat 19 Oct 85 13:31:17-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a002034; 19 Oct 85 14:52 EDT
Received: from simtel20.arpa by AOS.BRL.ARPA id a006436; 19 Oct 85 14:55 EDT
Date: Saturday, 19 October 1985  12:16-MDT
Message-ID: <KPETERSEN.12152415929.BABYL@SIMTEL20.ARPA>
Sender: Bob Clements <clements@BBNCCQ.ARPA>
From: Bob Clements <clements@BBNCCQ.ARPA>
Subject:   Version 1.0 of WA8DED firmware for TAPR TNC-1
ReSent-From: KPETERSEN@SIMTEL20.ARPA
ReSent-To: Info-Cpm@BRL.ARPA
ReSent-Date: Sat 19 Oct 1985 12:54-MDT

This message announces the posting of version 1.0 of the WA8DED
firmware for the TAPR TNC-1.  It is being posted on SIMTEL20 on the
ARPANET. Some Usenet guru will have to carry on from there for the
usenet folks.

Version 0.91 was posted there previously. Version 1.0 has a few
additional features, mostly in the monitoring area, and a few bug
fixes.

The new files are available from SIMTEL20 as:

Filename			Type	 Bytes	 CRC

Directory MICRO:<CPM.PACKET>
TNCDED10.DOC.1			ASCII	 34730  3A91H
TNCDED10.HEX.1			ASCII	 46093  0F18H
TNCDED10.MSG.1			ASCII	  4022  85C3H

This firmware runs on the TAPR TNC-1 and its clones, the AEA and the
Heath HD-4040 TNCs.  It is NOT an upgrade of the TAPR code. It is a
completely new implementation of the AX.25 protocol, both the current
version 2.0 and the older 1.x version supported by the normal TAPR
code. It also supports up to four simultaneously open connections on
one TNC.  And it has a "host friendly" mode, which is intended to
simplify the interfacing of the TNC to a Bulletin Board or other
computer system. It has noticeably fewer protocol bugs than the TAPR
code, and a much more informative Monitor mode.

The command interface is NOT the same as the TAPR TNC code.  It is
therefore not just an improvement for your TNC, but a complete change
of the interface. So you might not want it if you (or your computer)
are used to the standard interface.

The files being posted are: This message, TNCDED10.MSG; The
documentation file, TNCDED10.DOC; and the binary of the code itself,
in Intel Hex format, in TNCDED10.HEX.

The code occupies two 2764 EPROMs (actually about 1.2 EPROMs - plenty
of space left in the second one).  The EPROMs reside at C000 and E000
of the TNC, sockets U11 and U12 respectively.  If you need to
manipulate this file with a CP/M DDT, remember to use an offset with
the I command so that you don't overwrite your DDT, BDOS and BIOS. Put
C000 through DFFF into the EPROM for U11, and put E000 through FFFF
into the EPROM for U12.

The code and documentation are copyrighted 1985 by Ronald Raikes,
WA8DED. They are submitted with his permission for non-commercial use
by individual Radio Amateurs. All other rights reserved by Ronald
Raikes.

The program is written in 6809 assembler. The source code is not being
posted, but is available from Ron by sending him an 8" SSSD CP/M
format disk in a reusable mailer with return postage.  Enclose a
letter agreeing to the above personal use restriction.  To ease the
load on Ron, I will also make copies under the same ground rules.

You can reach Ron by packet through the forwarding mailbox network.
Address him as WA8DED @ KD6SQ.  He is not on ARPANET or Usenet.  His
US mail address is:

	Ronald Raikes, WA8DED
	9211 Pico Vista Road
	Downey, CA 90240

If you want to mail me a disk, as offered above, I'm good in the
callbook.

73,
Bob, K1BC
ARPANET: clements@bbn
Usenet:  {ihnp4, decvax, linus}!bbncca!clements
Amateur Packet Radio BBS net: K1BC @ K1BC, via W0RLI

[Political statement: Boycott the TNC-2 until a maintenance release
of TNC-1 comes out!]

[Usual disclaimers and trademark notices]

The following message ported from the WA6OSA Packet Mailbox:

*** Message from WA6OSA to ALL entered Thursday 01-Aug-85 at 8:45 PM
*** Subject: ++NEW IMPROVED++ WA8DED FIRMWARE FEATURES

Version 0.9 of the WA8DED firmware for the TAPR TNC-1 compatables is
now available.  It is written in 6809 assembly language and is
contained in two 2764 EPROMs.  Some of its outstanding features are:

1. Up to four simultaneous connects (plus unproto).
2. Easy to read 'monitor' frame information in unproto mode.
3. Simple 'On Screen' Calibration.
4. Digipeats version 2 protocol.
5. Meaningful channel status display (separate status for each channel).
6. Supports modem baud rates up to 9600 baud.
7. New-Improved Host Mode (for computer interface).
8. Display of link state and number of free buffers.
9. XON-XOFF flow control
10.Auto-Unattended/Beacon Mode.

Version 1.0 should be available around the first of September and is
contained in two 2764 EPROMS.  The W6IXU mailbox is currently using a
beta version 0.9 of the WA8DED firmware.
19-Oct-85 13:59:35-MDT,1466;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Sat 19 Oct 85 13:59:25-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a002093; 19 Oct 85 15:15 EDT
Received: from simtel20.arpa by AOS.BRL.ARPA id a006459; 19 Oct 85 15:11 EDT
Date: Sat, 19 Oct 1985  13:10 MDT
Message-ID: <KPETERSEN.12152418843.BABYL@SIMTEL20.ARPA>
Sender: KPETERSEN@SIMTEL20.ARPA
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
To:   Eric Hestenes <hestenes%sdcsla.uucp@BRL.ARPA>
Cc:   Info-Cpm@BRL.ARPA
Subject: Classified ads

Eric, there is a bottom line to all this.  If the ads continue, the
gateway between net.micro.cpm and INFO-CPM will be discontinued.  I
don't think any of us want to see that.  We ALL gain a lot by the free
flow of information and ideas between readers on both networks.

Many net.micro.cpm readers have told me that they value my
announcements of new public-domain software as it becomes available,
even though they cannot access SIMTEL20.  They know that MOST of the
new files are available either on their local RCPM or my RCPM Royal
Oak (MI).

I suggest we terminate this discussion before someone decides to pull
the gateway.  It's pointless to argue who is right.

--Keith Petersen
Arpa:  W8SDZ@SIMTEL20.ARPA
uucp:  ...!seismo!SIMTEL20.ARPA!W8SDZ
uucp:  ...!{decvax,unc,hao,cbosgd,seismo,aplvax,uci}!brl-bmd!w8sdz
uucp:  ...!{ihnp4!cbosgd,cmcl2!esquire}!brl-bmd!w8sdz
19-Oct-85 23:40:35-MDT,2914;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Sat 19 Oct 85 23:40:26-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a002877; 20 Oct 85 1:18 EDT
Received: from simtel20.arpa by AOS.BRL.ARPA id a007268; 20 Oct 85 1:17 EDT
Date: Sat, 19 Oct 1985  23:17 MDT
Message-ID: <KPETERSEN.12152529269.BABYL@SIMTEL20.ARPA>
Sender: KPETERSEN@SIMTEL20.ARPA
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
To:   ABN.ISCAMS@USC-ISID.ARPA
Cc:   emigh%ecsvax.uucp@BRL.ARPA, pencin.dlos@XEROX.ARPA, Info-Cpm@BRL.ARPA
Subject: SCAN -- reinventing the wheel? What about BISHOW31?

    Re:   SCAN -- a program to look at text and squeezed files

    (Russ responded to Ted Emigh about SCAN, suggesting it might be a good
    extension to bishow.)

    (David did a hack and put assembler routines for Unsqueezing squeezed
    text files into BISHOW.)

Hold on there!  Aren't you all reinventing the wheel?  I thought
everyone know about:

Filename                        Type     Bytes   CRC

Directory MICRO:<CPM.TXTUTL>
BISHOW31.AQM.1                  BINARY   32384  525DH

This version has been around a LONG time (since January 1984).
It will read normal or squeezed files AND files inside LBRs!

Here is a short bit of the update history:

title   'BISHOW v3.01 - buffered bidirectional file scroll utility'

Ver 3.01, 15 Jan 84, Frans van Duinen, Toronto, Ont
        - made unsqueeze message optional
        - added library capability
        - fixed bug in conditional assembly of CLRSCR

Ver 2.09, 7 Jan 84, Frans van Duinen, Toronto, Ont
        - Modified USQ routines for higher speed (+10%) and
          less memory usage.
        - made USQ code optional through conditional assembly
        - fixed a bug introduced with 2.08 and SHORT=TRUE 
          (resulted from ASM's inability to nest IF/ENDIF) 
        - fixed a bug  that reset FCBEX after open, whenever
          sector 0 was read, (this resulted in BDOS assuming that
          the current extent, whose allocation group nos were still
          in the FCB, was the correct one. 
        - Changed exit to clear screen only on Q or ^C exit,
          to leave any messages visible
        - Made wait after clear screen a cond assembly option

Ver 2.08, 2 Jan 84, Frans van Duinen, Toronto, Ont
        - added squeezed file capability
        - added sidewise scrolling on ^I, ^L, steps of 8
        - Osborne support for cursor keys, clr scr & scr size
        - Changed FILBAK rtn to recognize top of file
        - Set up flag to avoid unnecessary re-reading of
          top of file 

        The unsqueeze code was lifted from the USQ base code
        by Dave Rand (Edmonton, Alberta) as adapted for LTYPE1
        by S.Kluger (El Paso,Texas)
        The code was lifted to allow continued use of ASM.COM 

--Keith
20-Oct-85 00:06:26-MDT,1509;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Sun 20 Oct 85 00:06:15-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a002930; 20 Oct 85 1:40 EDT
Received: from simtel20.arpa by AOS.BRL.ARPA id a007317; 20 Oct 85 1:38 EDT
Date: Monday, 14 October 1985  04:33-MDT
Message-ID: <KPETERSEN.12152531132.BABYL@SIMTEL20.ARPA>
Sender: Chuck Forsberg WA7KGX <tektronix!reed!omen!caf@UW-BEAVER.ARPA>
From: Chuck Forsberg WA7KGX <tektronix!reed!omen!caf@UW-BEAVER.ARPA>
Subject:   Latest YMODEM.DOC revision available
ReSent-From: KPETERSEN@SIMTEL20.ARPA
ReSent-To: Info-Cpm@BRL.ARPA
ReSent-Date: Sat 19 Oct 1985 23:27-MDT

A revision of YMODEM.DOC, describing the XMODEM, XMODEM/CRC, and
YMODEM protocol is now available via FTP from SIMTEL20 as:

Filename			Type	 Bytes	 CRC

Directory MICRO:<CPM.YAM>
YMODEM.DQC.1			BINARY	 31232  8841H <--squeezed
  ...and
Directory MICRO:<CPM.MODEM2>
YMODEM.DOC.1			ASCII	 49446  6076H

The YMODEM extensions include 1k packets for greater throughput,
batch file transfers to minimize keystrokes and user time,
exact file length, and file modification date.

-- 
  Chuck Forsberg WA7KGX   ...!tektronix!reed!omen!caf   CIS:70715,131
Omen Technology Inc     17505-V NW Sauvie Island Road Portland OR 97231
Home of Professional-YAM
Voice: 503-621-3406     Modem: 503-621-3746 (Hit CR's for speed detect)
omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp
20-Oct-85 07:30:55-MDT,1871;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Sun 20 Oct 85 07:30:47-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a003592; 20 Oct 85 9:06 EDT
Received: from mit-mc.arpa by AOS.BRL.ARPA id a007903; 20 Oct 85 9:03 EDT
Received: from rice.ARPA by MIT-MC.ARPA 20 Oct 85 08:59:22 EDT
Received: by rice.ARPA (AA24043); Sat, 19 Oct 85 16:56:13 CDT
Date:     Sat, 19 Oct 85 15:51:43 CDT
From: Paul Milazzo <milazzo@RICE.ARPA>
Subject:  Re: Where's the DMA Address?
To: pete%stc.uucp@BRL.ARPA
Cc: info-cpm@AMSAA.ARPA
Message-Id: <1985.10.19.15.51.44.830.23545@Dione.rice>
In-Reply-To: <647@stc-b.stc.UUCP>

	"Now, sooner or later my interrupt routine is going to want
        to read a sector from the RAM-disk when an application
        program has set the DMA address to somewhere other than the
        default area."  - Peter Kendell <pete@stc.UUCP>

Worse yet, it might try to do so during the execution of another system
call.  In the case of CP/M 2.2 you can probably guard against this
eventuality simply by checking for saved PC >= base of BDOS.  For CP/M+
one would also have to test for BANK not equal to 1 (as well as assure
the interrupt service routine resides in common memory!).  Is there a
better way, anyone?

As for finding the DMA address, in CP/M+ it's kept in SCB+3C, but for
2.2 I'm not sure.  It is passed to BIOS function 12 (SETDMA), so if you
have BIOS source you can figure out where your BIOS saves it.  If not,
you might have to resort to disassembling BDOS function 26 (sigh...).

				Paul G. Milazzo
				Dept. of Computer Science
				Rice University, Houston, TX

Domain:	milazzo@rice.EDU
ARPA:	milazzo@rice.ARPA
BITNET:	milazzo@rice-net, milazzo@ricecsvm
UUCP:	{cbosgd,convex,cornell,hp-pcd,shell,sun,ut-sally,waltz}!rice!milazzo

20-Oct-85 09:14:24-MDT,1131;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Sun 20 Oct 85 09:14:16-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a003711; 20 Oct 85 10:48 EDT
Received: from usenet by TGR.BRL.ARPA id a023868; 20 Oct 85 10:51 EDT
From: Jan Steinman <jans%mako.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: C compiler info
Message-ID: <935@mako.UUCP>
Date: 19 Oct 85 04:23:57 GMT
To:       info-cpm@AMSAA.ARPA

In article <2130@brl-tgr.ARPA> Ghenis.pasa@XEROX.ARPA writes:
>...MIX C was been prematurely anounced at $39.95 three months ago
>and they aren't shipping yet (hmm...).

Agreed, it was prematurly anounced, by they *are* shipping.  Someone I
worked with just got his copy.  Some time ago, I posted a favorable
review for the MIX editor.  In all my spare time :-) I plan to evaluate
the MIX compiler, also.



-- 
:::::: Artificial   Intelligence   Machines   ---   Smalltalk   Project ::::::
:::::: Jan Steinman		Box 1000, MS 61-405	(w)503/685-2956 ::::::
:::::: tektronix!tekecs!jans	Wilsonville, OR 97070	(h)503/657-7703 ::::::
20-Oct-85 17:34:48-MDT,1236;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Sun 20 Oct 85 17:34:42-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a004658; 20 Oct 85 18:40 EDT
Received: from usenet by TGR.BRL.ARPA id a028086; 20 Oct 85 18:43 EDT
From: jp@LANL.ARPA
Newsgroups: net.micro,net.micro.cpm
Subject: VIASYN Concurrent DOS8-16
Message-ID: <32145@lanl.ARPA>
Date: 20 Oct 85 15:02:12 GMT
Xref: seismo net.micro:13130 net.micro.cpm:5153
To:       info-cpm@AMSAA.ARPA


I have a Compupro computer which I upgraded to use the Macrotech
MI-286 board, which is a direct replacement for the Compupro 8088/85
board.  I would like to upgrade my operating system to Concurrent
DOS8-16, but, Compupro has fixed up their loader and SW! programs to
detect the non-Compupro board.  Does anyone know how to either change
the software so it thinks everything is OK or to fix the harware to the
same end.  The Macrotech board was sufficiently expensive that I find
changing to Viasyn's 286 and Z-80 boards unattractive.  And I don't want to
buy the Concurrent DOS without some assurance that it can be made to
work with the Macrotech board.

Thanks,

Jim Potter  jp@lanl.arpa
21-Oct-85 01:18:56-MDT,975;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Mon 21 Oct 85 01:18:51-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a005318; 21 Oct 85 2:52 EDT
Received: from usenet by TGR.BRL.ARPA id a002365; 21 Oct 85 2:47 EDT
From: ir320 <ir320%sdcc6.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: MIX C compiler and Editor?
Message-ID: <2250@sdcc6.UUCP>
Date: 19 Oct 85 19:40:23 GMT
To:       info-cpm@AMSAA.ARPA

Has anyone out there tried the MIX C compiler and Editor for CP/M?  What do
you think of it?  It is better than the Manx Aztec CII compiler?  What is
the code like?  How complete is it?  How fast?  Any advice given will be
greatly appreciated.

John Antypas
UC San Diego

uucp:
...!{sdcc3,sdchem,ucbvax,decvax,ihnp4,noscvax,bang}!sdcsvax!sdcc6!ir320
...!{sdcsvax,ihnp4}!gwsd!man!wolf!u0236879

arpa: 
   ir320%sdcc6@sdcsvax.ARPA   sdcsvax!gwsd!man!wolf!u0236879@Nosc.ARPA
21-Oct-85 05:04:12-MDT,1362;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Mon 21 Oct 85 05:04:06-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a005649; 21 Oct 85 6:40 EDT
Received: from usenet by TGR.BRL.ARPA id a004829; 21 Oct 85 6:40 EDT
From: jp@LANL.ARPA
Newsgroups: net.micro.cpm
Subject: HELP: problem with LIST device in MEX
Message-ID: <32179@lanl.ARPA>
Date: 21 Oct 85 06:18:00 GMT
To:       info-cpm@AMSAA.ARPA


I have just recently brought up MEX114 on my Compupro system.  As it
stands when I try to use the echo-screen-to-printer mode the whole
system hangs after 100 or so characters.  If I put pointers to my
own routines in the list output vector and the list status vector, I
find that the status routine is called frequently and the list device
is ready, but there never seems to be a call to the output routine.
All of this is probably cockpit trouble, but while I'm struggling I
thought I would put out a query in the faint hope that someone will
say "Oh, yeah.  What you need to do is..."
By the way, the symptoms are the same under CP/M-80 and CP/M-816.

Any thoughts would be appreciated.

p.s.  I vaguely recall having a problem with the list status returned
by my BIOS when I installed MODEM730 a while back.  Very strange.

Thanks,

Jim Potter  jp@lanl.arpa
21-Oct-85 08:47:56-MDT,1695;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Mon 21 Oct 85 08:47:46-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a011496; 21 Oct 85 10:02 EDT
Date: Sat, 19 Oct 1985  08:58 MDT
Message-ID: <KPETERSEN.12152372974.BABYL@SIMTEL20.ARPA>
Sender: KPETERSEN@SIMTEL20.ARPA
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
To:   Richard Thomsen <rgt%a@LANL.ARPA>
Cc:   Info-Cpm@AMSAA.ARPA
Subject: CP/M help on Find Next - unlimited number of names

A complete routine for doing the search-first/search-next without
building a table (i.e., has NO limit on the number of file names) is
included in my COPYFILE program.  It's available from SIMTEL20 as:

Filename			Type	 Bytes	 CRC

Directory MICRO:<CPM.FILCPY>
CPYFIL15.LBR.1			BINARY	  8576  AAECH

This program will copy files of any length from one drive to another,
with 16k (optionally larger) buffering.  It was created for very long
files (megabyte length), which are not properly handled by CP/M 2.x
PIP.  This version offers selective copying of files - something not
available with PIP.  The destination files will have NO attributes
set, which is useful for copying from CP/M 2.x to 1.4 disks.

COMMANDS:
	COPYFILE [drive:]<filename.filetype> <destination drive:>[/S]
	Requires the use of the /S option if transfer
	of files with SYS attribute is wanted.

EXAMPLES:
	COPYFILE MYFILE.ASM B:
		gets MYFILE.ASM from default disk and copies to B:
	COPYFILE A:MYFILE.ASM B:
		gets MYFILE.ASM from A: and copies to B:
	COPYFILE B:*.* A:
		gets all files from B: and copies to A:
		
All normal ambiguous file names are allowed.

--Keith
21-Oct-85 08:50:50-MDT,1203;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Mon 21 Oct 85 08:50:44-MDT
Date:     Mon, 21 Oct 85 10:05:13 EDT
From:     David Towson (SECAD) <towson@AMSAA.ARPA>
To:       info-cpm@AMSAA.ARPA
Subject:  AMSAA is temporarily in netmail limbo:

Fellow CP/Mers - After a LONG wait for new network access hardware, AMSAA.ARPA
(the machine from which info-cpm is distributed) is now on the BRL fiber-optic
ring-net with a new net address, 192.5.24.10.  Unfortunately, at this time
it's a case of "close-but-no-cigar" because the network host tables have not
been updated yet; that should happen soon.  The old net interface still works,
and still answers to the old net address, 128.20.3.1, but only if it is
plugged-in, which at this moment it is not.  Therefore, incoming mail may be
sporadically rejected for a day or two longer.  But once the new net address
is propagated, AMSAA should settle down to being on the net 24 hours a day
like in the "good old days" before lightening zapped the network interface.

     Just a little longer, folks...



Dave
towson@amsaa.arpa  (aka info-cpm-request@amsaa.arpa)

21-Oct-85 09:19:47-MDT,2152;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Mon 21 Oct 85 09:19:22-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a012033; 21 Oct 85 10:11 EDT
Date: Sun, 20 Oct 1985  00:07 MDT
Message-ID: <KPETERSEN.12152538505.BABYL@SIMTEL20.ARPA>
Sender: KPETERSEN@SIMTEL20.ARPA
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
To:   Info-Cpm@AMSAA.ARPA
Cc:   Info-Micro@brl-vgr.ARPA
Subject: SB180 users group formed

If you own or plan to buy or build the SB180 super 8-bit computer
designed by Steve Ciarcia of BYTE magazine and manufactured by
Micromint you may wish to look into becoming a member of N.A.O.G.  It
has been formed on Steve's suggestion and with the cooperation, but
NOT ownership, of Micromint.

The N.A.O.G. newsletter will be delivered via first-class mail each
month, starting in January.  It will be edited by User's Guide
"Advanced User" columnist Bruce Morgen, former Computer Editor of
Electronic Products magazine.  Each newsletter will contain news of
the latest SB180-compatible hardware and software, including Z-System
hints and tutorials, news of the latest program revisions and hardware
upgrades from Micromint and from the N.A.O.G. membership.

Starting with the second newsletter, disks will be available to
members for a little over the cost of media and mailing, each with
about 300K of software as described in the preceding newsletters.

The North American One-Eighty Group will be officially announced in
the December BYTE, the issue that will include Steve's new Turn-Key
Bulletin Board System (TKBBS), based on the SB180, the new COMM180
modem/SCSI board, Rick Conn's TERM3 and Tim Gary's Z-Msg software.

An introductory one-year N.A.O.G. membership is $12 per year,
including twelve issues of the newsletter as well as user disk
privileges and access to the members-only sections of the N.A.O.G.
TKBBS remote system.

The address is:

	North American One-Eighty Group
	P.O. Box #2781
	Warminster, PA  18974
	voice phone: 215-443-9031
	TKBBS phone: to be announced in first newsletter and BYTE

--Keith
21-Oct-85 09:21:18-MDT,802;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Mon 21 Oct 85 09:21:11-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a012049; 21 Oct 85 10:11 EDT
Date: Sun 20 Oct 85 08:22:38-MDT
From: Rick Conn <RCONN@SIMTEL20.ARPA>
Subject: Re: Where's the DMA Address?
To: milazzo@rice.ARPA
cc: pete%stc.uucp@BRL.ARPA, info-cpm@AMSAA.ARPA
In-Reply-To: <1985.10.19.15.51.44.830.23545@Dione.rice>
Message-ID: <12152628589.16.RCONN@SIMTEL20.ARPA>

I know it doesn't help CP/M 2.2 users, but ZRDOS offers at GETDMA function
as well as a SETDMA function.  Hence, there's your answer in a Z-System
environment.  Also, since ZRDOS is one-level reentrant, you don't have to
worry about this happening during a DOS call.
	Rick
-------
21-Oct-85 10:12:29-MDT,644;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Mon 21 Oct 85 10:12:24-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a013256; 21 Oct 85 10:32 EDT
Received: from apg-3.arpa by AOS.BRL.ARPA id a015216; 21 Oct 85 10:29 EDT
Date: Mon, 21 Oct 85 10:22:07 EDT
From: John Shaver STEEP-TMAC 879-7602 <jshaver@APG-3.ARPA>
Subject: VDO
To: info-cpm@BRL.ARPA
Cc: jshaver@APG-3.ARPA

The VDO program currently at DDDin Simtel20 does not work on the Apple //e with
enhancement.  Has anyone else tried this on the Apple?   Can we get a message
back to the programmer?

21-Oct-85 11:47:37-MDT,2016;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Mon 21 Oct 85 11:47:27-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a012061; 21 Oct 85 10:11 EDT
Date: Sun, 20 Oct 1985  09:56 MDT
Message-ID: <KPETERSEN.12152645723.BABYL@SIMTEL20.ARPA>
Sender: KPETERSEN@SIMTEL20.ARPA
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
To:   well!micropro!edg@LLL-CRG.ARPA
Cc:   Info-Cpm@AMSAA.ARPA
Subject: uucp net access to SIMTEL20 PD files

    Is this stuff restricted only to persons on the arpanet?  I've been
    seeing lots of reference to PD material here in net.micro.cpm, but it
    seems that most all of it, and all of you, are out in ARPAland.  Is
    there any reason for a lowly uucp netter to be reading this stuff?

Ed, thanks for your note.  Simtel20 is not accessable from the uucp
net, unfortunately.  If you have access to an Arpanet or Milnet host
you can use FTP to get all the files you want.  Otherwise, your local
RCPM will be the best bet.  I post a complete list each month of all
known RCPMs to net.micro.cpm.

If you are unable to access SIMTEL20 because of network restrictions
please remember that MOST of the new files announced to Info-Cpm are
also available on my RCPM Royal Oak (MI) which may be accessed at 300
bps using the 103a modem mode or 1200 bps using either the 212a or
Vadic 3400 modes.  The telephone number is (313) 759-6569.

I don't consider uucp netters to be "lowly".  In fact I try very hard
to make new pd files available to them either via netmail (if the
files are small enough) or by making space available on my RCPM for
requested files.  I have received many comments from uucp readers
thanking me to keeping them up-to-date on what's new in the CP/M
PD world. 

--Keith Petersen
Arpa:  W8SDZ@SIMTEL20.ARPA
uucp:  ...!seismo!SIMTEL20.ARPA!W8SDZ
uucp:  ...!{decvax,unc,hao,cbosgd,seismo,aplvax,uci}!brl-bmd!w8sdz
uucp:  ...!{ihnp4!cbosgd,cmcl2!esquire}!brl-bmd!w8sdz
21-Oct-85 11:52:27-MDT,819;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Mon 21 Oct 85 11:52:19-MDT
Received: from usc-isid.arpa by AMSAA.ARPA id a015186; 21 Oct 85 11:33 EDT
Date: 19 Oct 1985 12:57-EDT
Sender: ABN.ISCAMS@USC-ISID.ARPA
Subject: Netiquette??
From: ABN.ISCAMS@USC-ISID.ARPA
To: info-cpm@AMSAA.ARPA
Cc: abn.iscams@USC-ISID.ARPA
Message-ID: <[USC-ISID.ARPA]19-Oct-85 12:57:47.ABN.ISCAMS>

NetLandians,
A recent conversation (re classified adds) mentioned a document (?)
called Netiquette .. first I'd heard of it.  Assume it's a Miss Manners
for net behavior/protocols/customs.

Can anyone point me to a copy?  I can FTP from my host if you'll set
the protection to read.

Thanks in advance,
David Kirschbaum
Toad Hall
ABN.ISCAMS@USC-ISID
21-Oct-85 11:56:37-MDT,1197;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Mon 21 Oct 85 11:56:29-MDT
Received: from usc-isid.arpa by AMSAA.ARPA id a015164; 21 Oct 85 11:32 EDT
Date: 18 Oct 1985 19:09-EDT
Sender: ABN.ISCAMS@USC-ISID.ARPA
Subject: Re: TURBO Question
From: ABN.ISCAMS@USC-ISID.ARPA
To: mdf%trwrba.uucp@BRL.ARPA
Cc: info-cpm@AMSAA.ARPA
Message-ID: <[USC-ISID.ARPA]18-Oct-85 19:09:56.ABN.ISCAMS>
In-Reply-To: <1637@trwrba.UUCP>

Mark,

Suggest you get the files
COMDEMO.PAS
COMDEMO.DOC
CLIB180.DOC
CLIB180.INC
from DEC-MARLBORO.ARPA, directory TURBO:

(If you don't have FTP capabilities, yell and I can mail them to you.)
They discuss comm ports with Turbo Pascal in the CP/M environment and
provide a fairly full shell for a modem program.

Also TKERMIT.LBR in directory CPM.TURBOPAS at our beloved archive,
SIMTEL20.ARPA, has a full (well, a shell anyway) KERMIT that uses the
CP/M IOBYTE to check the serial port.  Nice sample code there too.
(Tho that's a little big for mailing).

So if you can't reach any of these thru your nets, yell.
Regards,

David Kirschbaum
Toad Hall
ABN.ISCAMS@USC-ISID.ARPA
21-Oct-85 15:10:58-MDT,1442;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Mon 21 Oct 85 15:10:47-MDT
Received: from lanl.arpa by AMSAA.ARPA id a027778; 21 Oct 85 16:32 EDT
Received: from a.ARPA by LANL.ARPA (4.12/4.7)
	id AA23500; Mon, 21 Oct 85 14:35:06 mdt
Received: by a.ARPA (4.12/4.7)
	id AA19995; Mon, 21 Oct 85 13:39:24 mdt
Date: Mon, 21 Oct 85 13:39:24 mdt
From: Richard Thomsen <rgt%a@LANL.ARPA>
Message-Id: <8510211939.AA19995@a.ARPA>
To: kpetersen@SIMTEL20.ARPA
Subject: CP/M Find Next help
Cc: info-cpm@AMSAA.ARPA

Keith,

	Thanks for your help.  I downloaded CPYFIL15.LBR and set it up on
my Rainbow at work.  I looked at the way you did it, and it looked similar
to what I tried.  I made some modifications to my program, but it still did
not help.  Then I tried your COM file as it is in the library, specifing
*.* to be copied.  It, also, only found the first file and quit (just like
my program).  It looks like I am not doing anything wrong, but the Rainbow
version of CP/M is acting funny.  Oh well!  I will have to try something
else, I guess (such as building a table of names or counting the number
done so far).

	Anyway, thanks again for your help.

						Richard Thomsen
						rgt@lanl

PS:  I am sending a copy to INFO-CPM@AMSAA.  If anyone else has a Rainbow,
	try the MICRO:<CPM.FILCPY>CPYFIL15.LBR program and see if it works
	for you.
21-Oct-85 20:03:55-MDT,1008;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Mon 21 Oct 85 20:03:48-MDT
Received: from brl-aos.arpa by AMSAA.ARPA id a029831; 21 Oct 85 21:08 EDT
Received: from mit-mc.arpa by AOS.BRL.ARPA id a001835; 21 Oct 85 21:01 EDT
Received: from rice.ARPA by MIT-MC.ARPA 21 Oct 85 20:57:39 EDT
Received: from cleo by rice.ARPA (AA02378); Mon, 21 Oct 85 18:18:17 CDT
Received: by cleo (AA29071); Mon, 21 Oct 85 18:13:01 cdt
Date: Mon, 21 Oct 85 18:13:01 cdt
From: Hubert Daugherty <hd@RICE-CLEO.ARPA>
Message-Id: <8510212313.AA29071@cleo>
To: info-cpm@AMSAA.ARPA, jp@LANL.ARPA
Subject: Re:  VIASYN Concurrent DOS8-16

The local Viasyn dealer in Houston has replacement loader and SW! programs
that come from macrotek to get around your problem.  The company is:
	Informa, Inc.
	6633 Portwest Dr.
	suite 100
	Houston, TX 77024
	713-861-3330
I am not affiliated with Informa.
Hubert Daugherty @ Rice University
hd@rice.arpa

22-Oct-85 01:42:58-MDT,3793;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Tue 22 Oct 85 01:42:48-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a001458; 22 Oct 85 3:00 EDT
Received: from usenet by TGR.BRL.ARPA id a001925; 22 Oct 85 2:57 EDT
From: Eric Hestenes <hestenes%sdcsla.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: MIX C compiler and Editor?
Message-ID: <1011@sdcsla.UUCP>
Date: 21 Oct 85 08:39:39 GMT
To:       info-cpm@AMSAA.ARPA

> Has anyone out there tried the MIX C compiler and Editor for CP/M?  What do
> John Antypas
> UC San Diego


john,

i ordered the mix 'c' compiler about 3 weeks ago and it was shipped
( dated 10/15 ) to me this week. $45 including shipping. 

It appears to be a complete implementation of 'C' and has a large number
of unix-like and cpm-specific functions ( i.e. bdos/bios calls, chain ).

The manual is very large ( like a small telephone book ) and seems 
pretty good. It's loaded with examples ( about one example per 
item described ). The type-face stinks, though, and also the production
quality ( i.e. rather poor indexes. ) The manual compares to aztec, but that
might be as far as it goes. 

The compiler is quite slow, but appears to work ( for $40, the latter was
certainly in doubt. ) I tested it by compiling some xlisp source, and it
compiled without changes. It appears, though, that there are some kludges.
For example, to run an executable file you have to have a runtime
overlay on the disk, and the overlay ( that loads in the stdio package
) is loaded up ( slowly ) before the program runs. This seems artificial to
me. I should point out that a compiler option turns this off, but then one
isn't using i/o. 

The compiler in one pass creates an object file that can be passsed to the
linker.
Two utilities are provided that can be used before linking: a code speed
optimizer ( increases speed and code size ) and a code size optimizer 
( decreases size and speed ). I haven't had a chance to try these.

The code doesn't appear too fast, but i haven't tested it either with a
benchmark or by using the speedup utility. 

They do provide a full gamut of 'C' tools, from void constructs to
assigning structures to standard i/o functions. Also there is some source code
to some of the i/o functions ( fprintf, i think, etc ( ??? )).


Overall, I commend them on providing full K&R compatibility ( both the compiler
and the manual are highly compatible ). At this point I can't commend them
for runtime efficiency, nor for user interface ( as i would turbo pascal ).

However, for the price it is obviously excellent, especially given the
full K&R support ( including floats and longs, unix fns ( e.g. execl, execv,
printf, getc, etc )). 

For anyone on a budget, i recommend it, particularily for c novices
( there's a decent tutorial ). If you're rich, aztec is better, 
but maybe not for long. With several changes, this package could compete.
I should point out that it costs more for two books on 'C' than for this
compiler that includes a first-rate manual and is portable to many machines. 

Apple cpm users beware: 2 normal drives are not enough, unless you are fond of 
pulling floppies in and out of drives. A Unidisk 3.5 or a hard disk is
recommendable for this package, unless you have an editor that is smaller
than, say, wordstar. ( 30K ) One drive systems with less than 300K are out of
the question. However, it does work with 2 drives and 64k.

if anyone has specific questions, mail me and i'll try to answer them.

eric
---------
Eric Hestenes
arpanet: hestenes@nprdc.ARPA
other: ucbvax!sdcsvax!sdcsla!hestenes or hestenes@sdcsla.UUCP
[ is this considered an ad? I hope not :-) ]
22-Oct-85 12:49:08-MDT,1087;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Tue 22 Oct 85 12:48:58-MDT
Received: from css-ring-gw by AMSAA.ARPA id a017941; 22 Oct 85 14:09 EDT
Return-Path: <mcvax!ukc!stc.uucp!stc-b.uucp!pete>
Received: from mcvax.UUCP by seismo.CSS.GOV with UUCP; Tue, 22 Oct 85 14:07:53 EDT
Received: by mcvax.UUCP; Tue, 22 Oct 85 18:19:02 +0100 (MET)
Received: from stc by ukc.uucp id a000925; 22 Oct 85 17:33 BST
Received: from stc-b.UUCP (stc-b.SMTP) by stc.UUCP; Tue, 22 Oct 85 11:11:11 GMT
Date: Tue, 22 Oct 85 10:44:12 GMT
From: Peter Kendell <mcvax!stc!pete@seismo.ARPA>
Message-Id: <8510221044.AA16807@stc.UUCP>
To: milazzo@RICE.ARPA
Subject: Re: Where's the DMA Address?
Cc: info-cpm@AMSAA.ARPA

        Paul,

                Thanks for your message.

                I found the DMA address in my BIOS.  My current
        thoughts are centering around doing the whole lot in the
        BIOS, wasting bytes maybe, but avoiding BDOS hassles.

        Regards,

                Peter Kendell
22-Oct-85 12:53:31-MDT,2158;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Tue 22 Oct 85 12:53:16-MDT
Received: from xerox.arpa by AMSAA.ARPA id a017939; 22 Oct 85 14:09 EDT
Received: from PinotNoir.ms by ArpaGateway.ms ; 21 OCT 85 16:33:08 PDT
Date: 21 Oct 85 16:32 PDT
From: Ghenis.pasa@XEROX.ARPA
Subject: Re: MIX C compiler and Editor?
In-reply-to: ir320 <ir320%sdcc6.uucp@BRL.ARPA>'s message of 19 Oct 85
 19:40:23 GMT
To: ir320%sdcc6.uucp@BRL.ARPA
cc: info-micro@BRL-VGR.ARPA, info-cpm@AMSAA.ARPA, GHENIS.pasa@XEROX.ARPA
Message-ID: <851021-163308-334@Xerox>


FIRST-TIME IMPRESSIONS ON MIX-C AND MIX EDITOR (CP/M  version):

The prominently advertised MIX C compiler is finally being shipped. Mine
arrived yesterday (two months late). I hope the delay means that version
1.0 is fully functional and has not been rushed to the marketplace. I'd
rather wait than be irate.

Mild irritation: I ordered COD and MIX didn't tell me that they instruct
UPS *not* to accept personal checks.

So far I haven't had time to really test the compiler. I did some
standard trivial stuff last night and MIX C performed. The documentation
is a large and thick softcover manual that includes an introduction to
the C language. It seemed well structured and clear, with enough
examples. According to the manual most default settings can be changed
by the user (where to look for overlays, etc.) and programs can be
optimized for either size or speed. The standard libraries can also be
changed. Creation of overlays seems fairly painless since the linker
they provide appears to be quite programmer-friendly.

My first impression with my new toy is very positive. For $39.95 it
seems like a bargain (unless I uncover some crippling bug tonight...)

I also ordered the MIX Editor and I tend to agree with the positive
reviews posted on this list. I like the ability to split my screen and
edit two files at a time. It is programmable so you can redefine your
keyboard or even write editor procedures. It certainly is more editing
power than I expected to ever have on my CP/M system.


22-Oct-85 13:21:48-MDT,873;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Tue 22 Oct 85 13:21:35-MDT
Received: from xerox.arpa by AMSAA.ARPA id a017961; 22 Oct 85 14:10 EDT
Received: from Muscat.ms by ArpaGateway.ms ; 22 OCT 85 05:01:24 PDT
Date: Tue, 22 Oct 85 08:01 EDT
From: Kushall.henr@XEROX.ARPA
Subject: Re: Need help with Rainbow printer(LA50)
In-reply-to: <1016@bunker.UUCP>
To: "Michael S. Romaniw" <msr%bunker.uucp@BRL.ARPA>
cc: info-cpm@AMSAA.ARPA
Message-ID: <851022-050124-366@Xerox>

Mike:

The Rainbow uses XON/XOFF protocol.

I have a Rainbow and LA50 and have had no problem, here is how my
switches are set:

SW1 0-8 open
SW2 0-6,8 open 7 closed

The above switch settings are the 'as shipped default settings' as shown
on the LA50 manual on page 13.

Hope this helps.

Ed Kushall

22-Oct-85 13:54:58-MDT,791;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Tue 22 Oct 85 13:54:47-MDT
Received: from xerox.arpa by AMSAA.ARPA id a019917; 22 Oct 85 14:53 EDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 OCT 85 11:25:01 PDT
Date: Tue, 22 Oct 85 10:13 PDT
From: Doland.PA@XEROX.ARPA
Subject: Re: Classified ads
In-reply-to: <WANCHO.12151581188.BABYL@SIMTEL20.ARPA>
To: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
cc: Eric Hestenes <hestenes%sdcsla.uucp@BRL.ARPA>, INFO-CPM@AMSAA.ARPA
Message-ID: <851022-112501-1077@Xerox>

Can you direct me on how to get a copy of the document "Netiquette"
mentioned in your reply to Eric Hestenes.  I am relatively new to the
net.

-----Charlie Doland

<Doland.pa@XEROX.ARPA>

22-Oct-85 14:52:54-MDT,910;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Tue 22 Oct 85 14:52:41-MDT
Received: from mitre-bedford.arpa by AMSAA.ARPA id a023811; 22 Oct 85 16:19 EDT
Date: Tuesday, 22 Oct 1985 16:21-EDT
From: tom@MITRE-BEDFORD.ARPA
To: Ghenis.pasa@XEROX.ARPA
Cc: ir320%sdcc6.uucp@BRL.ARPA, info-micro@BRL-VGR.ARPA, info-cpm@AMSAA.ARPA, 
    GHENIS.pasa@XEROX.ARPA
Subject: Re: MIX C compiler and Editor?
In-reply-to: Your message of Monday, 21 Oct 1985 19:32-EDT.
             <851021-163308-334@Xerox>

Hi; I picked up your note on this C compiler from the net.  I own an APPLE IIE
with CPM, and I am interested in locating a good (cheap) C compiler.  I would
appreciate any information you may have on this subject, especially the
address of the company you bought your C from.

Thanks

Trevor O. McCarthy
The MITRE Corporation.
22-Oct-85 17:16:25-MDT,818;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Tue 22 Oct 85 17:16:10-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a025487; 22 Oct 85 18:47 EDT
Received: from usenet by TGR.BRL.ARPA id a022420; 22 Oct 85 18:46 EDT
From: Robert Jaquiss <robertj%tektronix.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Looking for a Morrow Md Ii
Message-ID: <5841@tektronix.UUCP>
Date: 22 Oct 85 00:53:56 GMT
To:       info-cpm@AMSAA.ARPA

I would like to find a Morrow Md Ii with DSDD drives.
I want to convert my system with SSDD drives to DSDD drives.
Thanks in advance.
Robert S. Jaquiss
ucbvax!tektronix!robertj (uucp)
robert jaquiss@tektronix (csnet)
robert jaquiss.tektronix@rand-relay (arpanet)
(503) 627-6346 (audio phone at work)
22-Oct-85 17:52:53-MDT,1142;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Tue 22 Oct 85 17:52:36-MDT
Received: from jpl-vlsi.arpa by AMSAA.ARPA id a009485; 15 Oct 85 7:02 EDT
Date:    Mon, 14 Oct 85 14:14:38 PDT
From:     spacerad@JPL-VLSI.ARPA
Subject: DAVID PLEASE POST FOR GENERAL INTEREST, DANTAS@JPL-VLSI.
To:       info-cpm-request@AMSAA.ARPA
Resent-Date:  Tue, 22 Oct 85 19:15:22 EDT
Resent-From:  cpmlist@AMSAA.ARPA
Resent-To:    info-cpm@JPL-VLSI.ARPA

 
THERE IS A NEW OPEN DATA BANK ON THE AIR.  
 
IT CONTAINS RADIATION EFFECTS DATA FOR TOTAL DOSE AND SINGLE EVENT UPSET (SEU)
TESTS CONDUCTED FOR NASA AND DOD.
 
IT IS EASY TO OPERATE.  
 
PHONE   818-354-5125
 
NAME    RADATA
 
PASSWORD  READ
 
PROT:     8 BIT
          1 BIT STOP
          NO PARITY
 
          AUTOMATIC 300 OR 1200 BAUD
 
 
PLEASE FEEDBACK ANY COMMENTS OR PROBLEMS.  THE DATA BANK IS NEWLY ON THE
AIR AND WE WOULD LIKE TO GET ALL THE BUGS OUT...IF THERE ARE ANY.
 
 
QUESTIONS OR INFO CONTACT:
 
MIKE GAUTHIER
JET PROPULSION LABORATORY
818-354-2126
GAUTHIER@JPL-VLSI.ARPA
22-Oct-85 18:24:42-MDT,8605;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA ([192.5.24.10].#Internet) by SIMTEL20.ARPA with TCP; Tue 22 Oct 85 18:24:11-MDT
Date:     Tue, 22 Oct 85 19:33:48 EDT
From:     Dave Towson (info-cpm-request) <cpmlist@AMSAA.ARPA>
To:       info-cpm@AMSAA.ARPA
Subject:  [nep.pgelhausen:  --- re: find first/next ---]
          [Tom Almy:  Re: Looking for WATFOR compiler]
          [Chuck McManis:  Re: A way to read 48 tpi disks on 96 tpi drives?]
          [Alan Gunderson:  SB180 & Tandon half-height drives]
          [Bob Halloran:  Re: A way to read 48 tpi disks on 96 tpi drives?]

Fellow CP/Mers - The following messages, all correctly addressed to info-cpm,
were delivered to the wrong address by our mailer.  Must be getting warmed up
for Halloween.  Let's try again...


Dave


----- Forwarded message # 1:

Received: from mit-multics.arpa by AMSAA.ARPA id a012510; 15 Oct 85 8:33 EDT
Received: from AMSAA by MIT-MULTICS.ARPA TCP; 15-Oct-1985 08:38:07-edt
Received: from ames-vmsb.arpa by AMSAA.ARPA id a009732; 15 Oct 85 7:07 EDT
Date: 11 Oct 85 16:46:00 PST
From: nep.pgelhausen@AMES-VMSB.ARPA
Subject: --- re: find first/next ---
To: info-cpm@AMSAA.ARPA
Reply-To: nep.pgelhausen@AMES-VMSB.ARPA

I tried sending this directly, but the mailer had some problems
w/ what I thought the address was, so re. the find/next problem:

If you can print the names properly, I would suggest COPYING
each name as find next finds them, then after all names have
been found use your list of file names to open each of them.

                              -Richard Hartman
                              max.hartman@ames-vmsb
------
------

----- Forwarded message # 2:

Received: from mit-multics.arpa by AMSAA.ARPA id a012587; 15 Oct 85 8:34 EDT
Received: from AMSAA by MIT-MULTICS.ARPA TCP; 15-Oct-1985 08:39:05-edt
Received: from brl-tgr.arpa by AMSAA.ARPA id a009773; 15 Oct 85 7:09 EDT
Received: from usenet by TGR.BRL.ARPA id a007812; 13 Oct 85 2:53 EDT
From: Tom Almy <toma%tekchips.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: Looking for WATFOR compiler
Message-ID: <283@tekchips.UUCP>
Date: 10 Oct 85 14:31:32 GMT
To:       info-cpm@AMSAA.ARPA

In article <1953@brl-tgr.ARPA> Kushall.henr@XEROX.ARPA writes:
>WATFOR stands for WATerlooFORtran and is an interactive Fortran interputer.
>It was developed by Waterloo University in Canada.
>
>The first machine to use it was the Commadore 9000 (Super PET).
>I don't know if ever was made available for any other machines.
>
>Ed

Gee, I used WATFOR in 1968 on an IBM 360.  They (Univ. of Waterloo) also
released in about that time frame WATFIV (WATerloo Fortran IV) and a
terrific Assembler.  I was very impressed with their compilers.

Tom

----- Forwarded message # 3:

Received: from mit-multics.arpa by AMSAA.ARPA id a014071; 15 Oct 85 9:02 EDT
Received: from AMSAA by MIT-MULTICS.ARPA TCP; 15-Oct-1985 09:06:19-edt
Received: from brl-tgr.arpa by AMSAA.ARPA id ab09773; 15 Oct 85 7:09 EDT
Received: from usenet by TGR.BRL.ARPA id a013920; 13 Oct 85 14:51 EDT
From: Chuck McManis <cem%intelca.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: A way to read 48 tpi disks on 96 tpi drives?
Message-ID: <120@intelca.UUCP>
Date: 11 Oct 85 15:21:24 GMT
To:       info-cpm@AMSAA.ARPA

> I am getting a new computer and need to decide whether to get 96 tpi drives
> or 48 tpi drives.  I know I get double the storage with 96 tpi, but I also
> give up disk compatability with them don't I?  Is there a way I could
> read/write a 48 tpi disks on a 96 tpi machine.  (The system is question
> is the new SB180 system described in Byte.)  Can other systems write disks
> for these drives?

The Ampro can read 48TPI disks on 96TPI drives, and since Joe Wright wrote
the BIOS for the SB180 and is/was heavily involved in the Ampro software I
suspect the SB180 will also support this capability. Another solution is
to spend the $20 for a single sided 48TPI drive and use it as a spare for
compatibility purposes.

--Chuck

--
                                            - - - D I S C L A I M E R - - -
{ihnp4,fortune}!dual\                     All opinions expressed herein are my
        {qantel,idi}-> !intelca!cem       own and not those of my employer, my
 {ucbvax,hao}!hplabs/                     friends, or my avocado plant. :-}

----- Forwarded message # 4:

Received: from mit-multics.arpa by AMSAA.ARPA id a015722; 15 Oct 85 9:29 EDT
Received: from AMSAA by MIT-MULTICS.ARPA TCP; 15-Oct-1985 09:34:00-edt
Received: from csnet-pdn-gw by AMSAA.ARPA id a010285; 15 Oct 85 7:27 EDT
Received: from gte-labs by csnet-relay.csnet id ab10495; 15 Oct 85 5:24 EDT
Received: by bunny.UUCP (4.12/5.03) id AA15284; Mon, 14 Oct 85 14:06:16 edt
          for
Date: Mon, 14 Oct 85 14:06:16 edt
From: Alan Gunderson <asg0%gte-labs.csnet@CSNET-RELAY.ARPA>
To: info-cpm@amsaa.csnet
Subject: SB180 & Tandon half-height drives

You can get one Tandon half-height drive to work with a SB180 system
by jumpering it so that the drive is selected all the time.  It should
also be jumpered so that the 'Motor On' function is NOT controlled by
the drive selection, i.e., the seperate 'Motor On' signal line is
used.  Having the drive selected all the time precludes the use of
multiple drives.  There appears to be a strange timing incompatability
between the disk controller on the SB180 and the Tandon drives.  I
think I may have to peel the drive select lines coming out of the disk
controller off and run them into some special circuitry and then into
the Tandon drives to be able to use multiple drives.  For now, I at
least can boot ZRDOS and make back ups.  Be informed that the Tandon
drives don't support the READY line.  You must jumper the JP6
selection on the SB180.  I installed a switch on this jumper, so that
I can get to the SB180 monitor.  When JP6 is wired permanently, the
monitor thinks the drive is always ready, and thus tries to autoboot.
You can fix this be reburning a new monitor PROM, but I haven't gotten
around to this yet.


====Alan Gunderson
uucp:  ...!seismo!harvard!bunny!asg0
csnet: asg0%gte-labs.csnet@csnet-relay.arpa


----- Forwarded message # 5:

Received: from mit-multics.arpa by AMSAA.ARPA id a017584; 15 Oct 85 10:16 EDT
Received: from AMSAA by MIT-MULTICS.ARPA TCP; 15-Oct-1985 10:20:27-edt
Received: from brl-tgr.arpa by AMSAA.ARPA id aa09773; 15 Oct 85 7:09 EDT
Received: from usenet by TGR.BRL.ARPA id a009858; 13 Oct 85 5:58 EDT
From: Bob Halloran <bobh%pedsgd.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: A way to read 48 tpi disks on 96 tpi drives?
Message-ID: <312@pedsgd.UUCP>
Date: 11 Oct 85 12:14:20 GMT
To:       info-cpm@AMSAA.ARPA

Organization : Perkin-Elmer DSG, Tinton Falls NJ

In article <2229@sdcc6.UUCP> ir320@sdcc6.UUCP (ir320) writes:
>I am getting a new computer and need to decide whether to get 96 tpi drives
>or 48 tpi drives.  I know I get double the storage with 96 tpi, but I also
>give up disk compatability with them don't I?  Is there a way I could
>read/write a 48 tpi disks on a 96 tpi machine.  (The system is question
>is the new SB180 system described in Byte.)  Can other systems write disks
>for these drives?

A 96tpi drive CAN read disks written on a 48tpi drive; the second part
of the construction article for that same SB180 implies as much.  The
BIOS needs some extra code to realize it must double-step for these
disk formats.  The major problem as I understand it is that in writing,
the 96tpi drive lays down a narrower 'track' than the 48tpi drive (makes
sense), which may either get lost against a previously written 'wide'
track if the disk has been used before in a 48tpi drive, or simply be
too narrow for the 48tpi drive's head to get a useful signal from.

Hope this helps.

                                                            Bob Halloran
                                                            Sr MTS, Perkin-Elmer DSG
=============================================================================
UUCP: {decvax, ucbvax, most Action Central}!vax135\
                               {topaz, pesnta, princeton}!petsd!pedsgd!bobh
ARPA: petsd!pedsgd!bobh@topaz
USPS: 106 Apple St M/S 305, Tinton Falls NJ 07724
DDD: (201) 758-7000
Disclaimer: My opinions are my own.
Quote: "It's Reagan's fault.  Everything's Reagan's fault.  Floods...
   volcanoes...  herpes... Reagan's fault." -- Editor Overbeek, Bloom Beacon

----- End of forwarded messages
23-Oct-85 06:10:38-MDT,2008;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 23 Oct 85 06:10:26-MDT
Received: from office-1.arpa by AMSAA.ARPA id a028579; 23 Oct 85 7:44 EDT
Date: 22 Oct 85 14:48 PDT
From: Alan Bomberger <ACB.COR@OFFICE-1.ARPA>
Subject: MIX editor
To: info-cpm@AMSAA.ARPA
Message-ID: <COR-ACB-7X34O@OFFICE-1>

Based on the recent interest in MIX C and Editor, I would like to reask a 
question I posted earlier.  Just after posting I lost my network connection due
to a change in address.  So I repeat the questions.  Sorry if I cause much 
repeating of answers.

Is the MIX editor written in Turbo?

I ask because the MIX editor does not run on my system and I want to avoid 
buying the language that it was written in.  Why does it not run you ask?  My 
system runs with interrupts active so that I can have console type ahead.  The 
MIX editor does everything but work with interrupts active.  Either the run 
time code is mismanaging the stack (say by fetching values from the stack 
"below" the stack pointer) or switching stacks and not leaving room for entries
caused by interrupts. I have no trouble if I run without interrupts.  I guessed
at Turbo because of the strange run time error messages I got about heaps and 
stacks that printed out when I tried it with interrupts enabled.

Other comments about MIX are that it is reasonably powerful.  I got it to 
behave like Magic Wand (my favorite editor) and its macro capability seems very
nice (especially for the price).  It is, however, VERY slow and VERY large 
(medium level languages have this problem).  Even with tons of overlays only a 
16K buffer is left on my 59K Northstar system (Magic Wand leaves over 40K).

I got it because it handles split screens and was programmable.  I will 
probably use it for those tasks that require those features.  Must be a lot 
better with bigger memories and faster CPU's.  Is writing fast, compact, and 
powerful code a lost art?

23-Oct-85 09:30:03-MDT,1240;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 23 Oct 85 09:29:57-MDT
Received: from lll-mfe.arpa by AMSAA.ARPA id a005703; 23 Oct 85 10:47 EDT
Date: Wed, 23 Oct 85 10:50 EDT
From: SECRIST%OAK.SAINET.MFENET@LLL-MFE.ARPA
Subject: UniFORTH Sampler
To: INFO-CPM@AMSAA.ARPA

Date:    Wed, 23-OCT-1985 10:50 EDT
To:      INFO-CPM@AMSAA.Arpa
Message-ID: <[OAK.SAINET.MFENET].DA29A2C0.008E4EFC.SECRIST>
X-VMS-Mail-To: ARPA%"INFO-CPM@AMSAA.Arpa"


Unified Software Systems of New Carrollton, MD has made the $35 sampler
version of their FORTH-83 CP/M-80 product available on bulletin boards
on the west coast and Florida.  The system is a precompiled version of
the full product, sans sources, fancy doc, and certain bells & whistles.

Has anybody run across it, and if so, WHERE ?!

Much grass.

Richard Secrist
SECRIST%OAK.SAInet.MFEnet@LLL-MFE.Arpa

P.S.> They also have the same product available for sundry micros and the
VAX.  I am in no way affliated with them, nor is this supposed to be an
ad, I just wanted to share the knowledge and find the sampler on a BBS.
It's supposed to live in a couple of squeezed libraries.  I do use their
VAX product and like it.
23-Oct-85 12:06:05-MDT,1546;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 23 Oct 85 12:05:46-MDT
Received: from xerox.arpa by AMSAA.ARPA id a012252; 23 Oct 85 12:58 EDT
Received: from PinotNoir.ms by ArpaGateway.ms ; 23 OCT 85 09:55:23 PDT
Date: 23 Oct 85 09:54 PDT
From: Ghenis.pasa@XEROX.ARPA
Subject: Re: Low price C compiler info
In-reply-to: u557593877ea <u557593877ea%ucdavis.uucp@BRL.ARPA>'s message
  of 10 Oct 85 09:20:00 GMT
To: u557593877ea%ucdavis.uucp@BRL.ARPA
cc: info-cpm@AMSAA.ARPA
Message-ID: <851014-114709-4438@Xerox>

The following message I sent apparently got lost by the mailer so I am
resending it. Please note that I have since received MIX-C and sent a
preliminary review to this group. Again, my personal feeling from what I
have had a chance to check out is that MIX-C is the best deal in
low-price C compilers, being fully K&R compatible.

----- Forwarded message # 1:

Think twice about getting BDS C: it may compile very fast, but it is
non-standard enough to make porting a pain. If you have no intention of
ever recompiling your code on another system that's fine, otherwise...

More standard low price compilers for CP/M are C/80 with Mathpak
(produces very efficient code) and Q/C (comes with source code!) among
others. MIX C was been prematurely anounced at $39.95 three months ago
and they aren't shipping yet (hmm...).

Check the C compiler reviews in Dr. Dobbs, Byte and Computer Language
for some very complete info.

----- End of forwarded messages
23-Oct-85 18:20:13-MDT,1421;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 23 Oct 85 18:20:02-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a025784; 23 Oct 85 19:46 EDT
Received: from usenet by TGR.BRL.ARPA id a018156; 23 Oct 85 19:43 EDT
From: John Blalock <jb%terak.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: C compiler info
Message-ID: <814@terak.UUCP>
Date: 21 Oct 85 18:33:31 GMT
To:       info-cpm@AMSAA.ARPA

>   I am interested in purchasing a C compiler and am consider the BDS compiler.
> I am using a Z80 system with CP/M80.  I would appreciate any thoughts or
> experiances on this or other low-priced compilers (under $200).
> Thanks in advance...

Be sure to check out the MIX C compiler.  When I called in my VISA order about
4 weeks ago, the CPM-80 version was ~3 weeks from shipping, seems they wanted to
update it to include features they'd added to the IBM-PC version.  I received
the CPM-80 version last week along with a very excellent manual.  The tutorial
is the best written introduction to C that I've found and I've looked at and/or
purchased many.  Now if the compiler is anywhere near as good as the manual...

John Blalock, W7AAY

uucp:	 ...{amd,decvax,hao,ihnp4,seismo}!noao!terak!jb
phone:	 (602) 998-4800
us mail: CalComp Display Products Division (formerly Terak Corporation)
         14151 N. 76th St., Scottsdale, AZ 85260
24-Oct-85 02:34:24-MDT,910;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 24 Oct 85 02:34:19-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a029541; 24 Oct 85 4:07 EDT
Received: from usenet by TGR.BRL.ARPA id a024278; 24 Oct 85 3:40 EDT
From: pete%stc.uucp@BRL.ARPA
Newsgroups: net.micro.cpm
Subject: DMA Address
Message-ID: <656@stc-b.stc.UUCP>
Date: 23 Oct 85 11:13:08 GMT
Xpath: stc stc-b stc-b stc-a
To:       info-cpm@AMSAA.ARPA


        I've been having some problems getting mail to ARPA addresses,
        so to:

                Keith Petersen
                Rick Conn
                Paul Milazzo
                Frank (wancho@simtel20.arpa)
                bomberger@office-1.arpa

        Thank you.  I appreciate your help.

        I'll post a brief summary presently.
-- 
	Peter Kendell <pete@stc.UUCP>

	...mcvax!ukc!stc!pete

	TANSTAAFL
24-Oct-85 05:37:57-MDT,853;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 24 Oct 85 05:37:52-MDT
Received: from sdcsvax.arpa by AMSAA.ARPA id a001187; 24 Oct 85 7:12 EDT
Received: by sdcsvax.ARPA (5.28/4.41)
	id AA11249; Wed, 23 Oct 85 23:25:22 PDT hops=0
From: crash!kevinb@SDCSVAX.ARPA
Message-Id: <8510240625.AA11249@sdcsvax.ARPA>
Date: Wed, 23 Oct 85 22:53:33 PDT
To: info-micro@BRL-VGR.ARPA
Subject: Netiquette Request
Cc: Info-CPM@AMSAA.ARPA, crash!kevinb@SDCSVAX.ARPA

  If possible, could someone contact me regarding the document called
Netiquette? I would really appreciate it so that I could pass it along
to others new to netland and as a guide to same. 

			Thanks in advance,

Kevin J. Belles - UUCP {ihnp4,cbosgd,sdcsvax,noscvax}crash!kevinb
~~~~~ ~~ ~~~~~~ - ARPA crash!kevinb@{ucsd,nosc}.ARPA

24-Oct-85 12:48:40-MDT,701;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 24 Oct 85 12:48:35-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a019592; 24 Oct 85 14:18 EDT
Received: from usenet by TGR.BRL.ARPA id a008725; 24 Oct 85 14:14 EDT
From: Yitz Twersky <compusci%aecom.uucp@BRL.ARPA>
Newsgroups: net.micro,net.micro.cpm
Subject: KAYPRO to TELEVIDEO?
Message-ID: <1969@aecom.UUCP>
Date: 23 Oct 85 21:53:17 GMT
Xref: seismo net.micro:13169 net.micro.cpm:5179
To:       info-cpm@AMSAA.ARPA

Is there a prograam that exists to read wordstar data files from a kaypro
to a televieo pc? something like media master or uniform on the IBM PC?

				Thanks
					Yitz
25-Oct-85 01:18:05-MDT,1344;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 25 Oct 85 01:17:59-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a029961; 25 Oct 85 2:41 EDT
Received: from usenet by TGR.BRL.ARPA id a021266; 25 Oct 85 2:43 EDT
From: Ron Heiby <heiby%cuae2.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: MDM740 latest?
Message-ID: <496@cuae2.UUCP>
Date: 22 Oct 85 19:52:08 GMT
To:       info-cpm@AMSAA.ARPA

I have just succeeded in getting a development environment that will allow
me to assemble large ASM programs for my CP/M system (Apple II based, small
floppies).  I am interested in upgrading my file transfer software to a
version more recent than MDM712, which is what I have been running.  I do
have MDM740, but not an example of the newer format overlay file for modem
configuration or phone number definition.  I also do not have the M7LIB
or M7FNK programs.
	A)  Does anyone have the files I am missing?
	B)  Is there a more recent / better file transfer program for
	    which source is available (ASM or BDS-C) that supports
	    CRC/Batch mode?  Can I get it?
Thanks much.
-- 
Ron Heiby {NAC|ihnp4}!cuae2!heiby   Moderator: mod.newprod & mod.unix
AT&T-IS, /app/eng, Lisle, IL	(312) 810-6109
"No; my legs are written in a functional programming language." (J. McKie)
25-Oct-85 05:53:26-MDT,1538;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 25 Oct 85 05:53:20-MDT
Received: from ucb-vax.arpa by AMSAA.ARPA id a001765; 25 Oct 85 7:26 EDT
Received: by UCB-VAX (5.29/5.13)
	id AA28078; Thu, 24 Oct 85 22:30:13 PDT
Received: from ucbopal.Berkeley.Edu (ucbopal.ARPA)
	by ucbjade.Berkeley.Edu (4.19/4.40)
	id AA03590; Thu, 24 Oct 85 22:32:35 pdt
Received: by ucbopal.Berkeley.Edu (4.19/4.39.1)
	id AA05020; Thu, 24 Oct 85 22:32:33 pdt
Date: Thu, 24 Oct 85 22:32:33 pdt
From: "William C. Wells" <wcwells@ucbopal>
Message-Id: <8510250532.AA05020@ucbopal.Berkeley.Edu>
To: crash!kevinb@SDCSVAX.ARPA, info-micro@BRL-VGR.ARPA
Subject: Re: Netiquette Request
Cc: Info-CPM@AMSAA.ARPA

	From info-cpm-request@AMSAA.ARPA Thu Oct 24 04:42:30 1985
	From: crash!kevinb@SDCSVAX.ARPA
	Message-Id: <8510240625.AA11249@sdcsvax.ARPA>
	Date: Wed, 23 Oct 85 22:53:33 PDT
	To: info-micro@BRL-VGR.ARPA
	Subject: Netiquette Request
	Cc: Info-CPM@AMSAA.ARPA, crash!kevinb@SDCSVAX.ARPA

	  If possible, could someone contact me regarding the document
	called Netiquette? I would really appreciate it so that I
	could pass it along to others new to netland and as a guide to
	same.

				Thanks in advance,

	Kevin J. Belles - UUCP {ihnp4,cbosgd,sdcsvax,noscvax}crash!kevinb
	~~~~~ ~~ ~~~~~~ - ARPA crash!kevinb@{ucsd,nosc}.ARPA

The document is part of the USENET news distribution and is known
as the "etiquette" file in Unix version of the USENET news software.

Bill Wells
25-Oct-85 13:07:30-MDT,706;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 25 Oct 85 13:07:20-MDT
Received: from xerox.arpa by AMSAA.ARPA id a015496; 25 Oct 85 14:29 EDT
Received: from CheninBlanc.ms by ArpaGateway.ms ; 25 OCT 85 11:32:08 PDT
Date: Fri, 25 Oct 85 11:31 PDT
From: LShilkoff.ES@XEROX.ARPA
Subject: Re: KAYPRO to TELEVIDEO?
In-reply-to: <1969@aecom.UUCP>
To: Yitz Twersky <compusci%aecom.uucp@BRL.ARPA>
cc: info-cpm@AMSAA.ARPA
Message-ID: <851025-113208-1395@Xerox>

"Is there a prograam that exists to read wordstar data files from a kaypro
to a televieo pc? something like media master or uniform on the IBM PC?"

Yes, Uniform for the Kaypro.

Larry

25-Oct-85 14:32:17-MDT,3842;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 25 Oct 85 14:32:03-MDT
Received: from apg-1.arpa by AMSAA.ARPA id a018085; 25 Oct 85 15:59 EDT
Date: Fri, 25 Oct 85 15:58:36 EDT
From: Robert Bloom AMSTE-TEI 3775 <rbloom@apg-1.ARPA>
Subject: Is CP/M Dead (or) Turbo buy fun
To: info-cpm@AMSAA.ARPA
Cc: rbloom@apg-1.ARPA

                               Is CP/M-80 dead?
                                      or
                  Fun in buying TurboPascal for my NorthStar


     When Adam Osborne was asked if he saw any future in CP/M-80 at a recent
seminar I attended, his answer was short and to the point: "None.  Next
Question?"

     Of course everyone laughed at that and I even kinda aggreed with the
statement.  While I thought that CP/M-80 would never actually die, it probably
would become a secondary option to IBM in small machines.  Then I tried to get
a discount copy of TurboPascal for my NorthStar Horizon running N* CP/M.

     Those that have organic memories going back a couple months remember a
want notice I posted on "Wanna buy TurboPascal for CP/M-80."  To all that
replied, thank you; I was surprised at the response.  Of the thirty or so
replies:

     - about half recommended going directly to Borland and buying it at the
retail of $69,
     - the other half contained various suggestions, some good, some not so
good.  There were two recommendations for "Spite Software" in, I think,
Washington State and two for "The Programmers's Shop" in Maine.
     - I even got several offers for pirate copies.

     All-in-all it took me about four weeks to actually receive a copy.  I
think I tried just about *all* of the 800 numbers in most of the popular
computer magazines.  The results of this informal survey in the basis for the
title of this note:  4/5ths of those called only offered MS-DOS software - the
other 1/5 would order CP/M stuff for a two to four week delay.  Only one had
it in stock and only one copy at that.  The magic words were *IBM*compatible*.
Yes, I knew that most micros sold are Irish Barf Models, but several sales-
people even asked if CP/M-80 was *IBM* *compatible*!  sheesh.
 
     I ended up buying the in-stock copy from the Programmers Shop and got it
10-14 days later.  (The guys there knew what CP/M was - and even asked the
right questions about disk format without prompting.)  A good place to deal
with.

     Through a bit of stupidity on my part, I actually brought and paid for
TWO copies, the other from a local dealer.  When one gets desperate and mad
one makes bad decisions.  (Anyone need a [factory-sealed] of Turbo copy for
CP/M?  And no, Frank, this is not an ad!)  The sum result was that my effort
to get a fast cheaper copy by going through mail-order backfired by being even
slower and more expensive.  My recommendation: buy directly from Borland.

     All-in-all, Osborne's comment kept coming back to me - despite CP/M-plus,
Echelon, ZCPR3, SB180, Richard Conn (sorry Rich), the dedication of thousands
of hackers, and the archives of Simtel20, CP/M *is* dying.  Even Digital
Research is no longer supporting it!  (That might not be a big loss though.)

     Is there anything we can (or should) be doing about that?  I just bought
an new z80 s-100 (N*) box - is it obsolete even before I pay it off?  The cost
to convert it to the magic IBM-compatible cost more than a separate new Irish
Barf Model PC.  Are we all going to go the way of the TI99a people?  And if we
go, aren't the 6502 Apple hackers right behind?  Or in front?

     As the cheerleaders say: 'Lets hear some *NOISE*!'

-bob bloom  (the thoughts above are mine and may not reflect reality as seen
by anyone else but me.  I have no relationship with anyone except my spouse.)

25-Oct-85 15:35:53-MDT,804;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 25 Oct 85 15:35:47-MDT
Received: from mit-multics.arpa by AMSAA.ARPA id a018806; 25 Oct 85 17:03 EDT
Date:  Fri, 25 Oct 85 16:52 EDT
From:  Boebert@MIT-MULTICS.ARPA
Subject:  Accounting and Database pkg needed
To:  Boebert@HI-MULTICS.ARPA, info-cpm@AMSAA.ARPA
Message-ID:  <851025205207.962693@MIT-MULTICS.ARPA>

Anybody have any recommendations for an accounting and a database
package which runs on CP/M and which would serve the needs of a church?
The accounting package would have to handle the sorts of financial data
one would expect for a church operation and the database would have to
handle membership and mailing lists.  Simple user interfaces are
naturally a premium consideration.
25-Oct-85 17:31:50-MDT,1305;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 25 Oct 85 17:31:42-MDT
Received: from usc-isid.arpa by AMSAA.ARPA id a019553; 25 Oct 85 19:01 EDT
Date: 25 Oct 1985 19:04-EDT
Sender: ABN.ISCAMS@USC-ISID.ARPA
Subject: Re: Is CP/M Dead (or) Turbo buy fun
From: ABN.ISCAMS@USC-ISID.ARPA
To: rbloom@APG-1.ARPA
Cc: info-cpm@AMSAA.ARPA
Message-ID: <[USC-ISID.ARPA]25-Oct-85 19:04:08.ABN.ISCAMS>
In-Reply-To: The message of Fri, 25 Oct 85 15:58:36 EDT from Robert Bloom AMSTE-TEI 3775 <rbloom@apg-1.ARPA>

Bob,

Enjoyed your trials narrative better than you probably enjoyed the trials!
Wish I had an answer to the fading popularity of CP/M .. I'm sitting here
with my good and faithful Toad (Morrow Decision I, S100) and the stolid and
mysterious Beast (CompuPro S100 multi-user with Gifford MP/M 816), yet all
my most recent developmental work is in the flashy Gulfstream..
NOT because it's a better programming environment (ugh), but only because
(1) that's where the markets are
(2) bloody people seem to want flash out there (e.g., popup windows,
    fancy screens, everything at their fingertips at the same time but
    "don't expect ME to read a manual", etc.

Sigh ...

Regards,
David Kirschbaum
Toad Hall
ABN.ISCAMS@USC-ISID
25-Oct-85 18:06:03-MDT,1578;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 25 Oct 85 18:05:49-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a019487; 25 Oct 85 18:54 EDT
Received: from usenet by TGR.BRL.ARPA id a011660; 25 Oct 85 18:52 EDT
From: "Wilson H. Bent" <whb%vax135.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Wanted: CP/M <=> RT/11
Message-ID: <1214@vax135.UUCP>
Date: 25 Oct 85 17:40:21 GMT
To:       info-cpm@AMSAA.ARPA

[The memory queue pushed this one out the back...]

At some point in the recent past, on one of the several (many)
RCP/M systems I'm involved with, I saw a library with a program
to do disk transfers/reads/something between CP/M and RT/11.

Now a friend of mine with an RT/11 system has expressed an interest in it,
and I can't find it!!!

Since it was a CP/M program, I'm assuming that it was good only for
reading RT/11 files into CP/M.  Fine, I'll take what I can get.

I don't have ARPA access, but I check these RCP/M systems fairly often:
	Lillipute:	(312) 649-1730	(Chicago)
	Voorhees:	(609) 428-8864	(Southern NJ)

Plus there's always my uucp address, which I'm hoping will show up
with my .signature - oh, what the heck, I'll risk it being here twice...

Wilson H. Bent, Jr.		... ihnp4!vax135!hoh-2!whb
AT&T - Bell Laboratories	(201) 949-1277
Disclaimer: My company has not authorized me to issue a disclaimer.
-- 
Wilson H. Bent, Jr.		... ihnp4!vax135!hoh-2!whb
AT&T - Bell Laboratories	(201) 949-1277
Disclaimer: My company has not authorized me to issue a disclaimer.
26-Oct-85 00:33:13-MDT,2088;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 26 Oct 85 00:33:05-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a020290; 26 Oct 85 2:00 EDT
Date: Sat, 26 Oct 1985  00:03 MDT
Message-ID: <WANCHO.12154110636.BABYL@SIMTEL20.ARPA>
From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
To:   Robert Bloom AMSTE-TEI 3775 <rbloom@APG-1.ARPA>
Cc:   WANCHO@SIMTEL20.ARPA, INFO-CPM@AMSAA.ARPA
Subject: Is CP/M Dead (or) Turbo buy fun

Bob,

First, let's clarify one point: if you judge the vitality of an
operating system, or anything else for that matter, on the basis of
vendor support, then there are many popular, but dead products out
there.

In the case of CP/M and DRI, it was CP/M-Plus that was put out to
pasture under the heading of Level "D" support "for mature products
that are not actively supported".  CP/M 2.2 (CP/M-80) has been
assigned Level "C" support, which is limited to questions submitted on
CompuServe and phone calls.

Now, that is not as good as Level "B" ("active support", meaning
they'll eventually answer letters, too) nor Level "A".  But, it's not
dead, or in the "mature" catagory as far as DRI is concerned.

Of course, the counter argument is that CP/M-80 was never supported by
DRI in the first place.  Ever try to call in the early days and get an
answer?

Just because Adam Osborne says there's no future in CP/M-80 doesn't
mean that it is dead.  There's a difference.  The market for CP/M is
simply mature and mostly saturated.  If you're going to write
software, don't bother writing for CP/M - write for the hungry mass
market that's still trying to catch up with the rest of us using
tight, functional, and efficient programs.  There's a future and a
fortune there, not in CP/M.

There are about maybe 2 million CP/M users out there, many of them
perfectly content with what they have and don't need anything else.
See Jerry Pournelle's column this month for one, possibly prevelant
viewpoint, at least among us diehards, and note that Jerry has a
choice.

--Frank
26-Oct-85 07:35:18-MDT,502;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 26 Oct 85 07:35:07-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a020958; 26 Oct 85 9:05 EDT
Received: from usenet by TGR.BRL.ARPA id a020998; 26 Oct 85 8:59 EDT
From: generous%styx.uucp@BRL.ARPA
Newsgroups: net.micro.cpm,net.micro
Subject: cancel <14764@styx.UUCP>
Message-ID: <14766@styx.UUCP>
Date: 24 Oct 85 00:26:45 GMT
Control: cancel <14764@styx.UUCP>
To:       info-cpm@AMSAA.ARPA


26-Oct-85 07:39:20-MDT,2198;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 26 Oct 85 07:39:14-MDT
Received: from brl-tgr.arpa by AMSAA.ARPA id a020960; 26 Oct 85 9:06 EDT
Received: from usenet by TGR.BRL.ARPA id a021013; 26 Oct 85 9:00 EDT
From: "Curtis C. Generous" <generous%styx.uucp@BRL.ARPA>
Newsgroups: net.micro,net.micro.cpm
Subject: Compupro 10+ Documentation
Message-ID: <14767@styx.UUCP>
Date: 24 Oct 85 00:32:44 GMT
Xref: seismo net.micro:13198 net.micro.cpm:5189
To:       info-cpm@AMSAA.ARPA

To anyone who has/is using a Compupro 10+ micro with CCPM/8-16:

  I have been using a 10+ for several weeks now, and have become
exasperated with the Compupro documentation (or lack of). 
If there is anyone out there who has done system level programming
on this machine, I would like to talk to you concerning some very basic yet 
undocumented features/commands.  For example:

	- How does one reset the real time clock.  The documentation
	  mentions the following: 
		   A>  DATE SET
	  But that does not seem to work.

	- The 10+ supports several printers, yet it is not documented
	  anywhere how to access them and switch printers from within
	  a program (assembly language, Pascal, C, etc..)

	- The operating system seems to have a bug concerning the 
	  release of the printers.  When more than one user tries to 
	  print a document to a common printer from within a program 
	  (i.e. Wordstar, Dbase), the second user's program seems to 
	  hang until the first users exits his program (back to the
	  system prompt).

	- Is it possible to detach the console as in MP/M, to run
	  a background task with CCP/M 8-16?

Also, if anyone has any hardware reference manuals for the machine, 
I would also like to find out how the communications are done between
the Z80`s and the 8088 CPU/Disk Drives.

I have made several attempts to contact D.R.I., the dealer where I
bought the system, and even Compupro to get some of these answers
but all in vain.  Any help in an of the above topics is appreciated.


Curtis C. Generous
generous@lll-tis-b.ARPA
{akgua,allegra,cbosgd,decwrl,dual,ihnp4,sun}!idi!styx!generous
27-Oct-85 06:09:05-MST,3644;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 27 Oct 85 06:08:48-MST
Received: from brl-tgr.arpa by AMSAA.ARPA id a023283; 27 Oct 85 7:40 EST
Received: from usenet by TGR.BRL.ARPA id a004069; 27 Oct 85 7:46 EST
From: Mark Mallett <mem%sii.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: More on MIX C
Message-ID: <428@sii.UUCP>
Date: 25 Oct 85 11:28:09 GMT
To:       info-cpm@AMSAA.ARPA

I also got my MIX C compiler a week or two ago and agree with all the
positive things that have been said about it here.  It seems to be
an excellent buy for $39.95 (or $45 with COD)-  it comes with a thick
paperback-book manual with C tutorial, reference, and lots of examples
(there are some errors in the examples so the proofreading may not have
been great).  The compiler can produce listing files. The linker supports
libraries-- you manipulate a library by converting it to an ASCII form and
editing it!  The linker can deal with either the ASCII or binary form (it
appears that the binary form has an awful lot of overhead in it, but no
matter there).  Multiple overlay areas are supported, which is nice on
a CPM80 system.

On the negative side:

	- the linker seems incredibly picky.  If you don't give it the
	  commands in the right sequence, you can get a fatal error message
	  or, worse yet, your program simply won't work.

	- you can define multiple overlay regions in your program, but
	  each region is a fixed size and must be big enough for the largest
	  overlay you are going to put in there.  I would much rather see
	  a hierarchical overlay structure, where overlay boundaries depend
	  on the definition of the higher-level overlay.  But again, for
	  $40 this is great.

	- The minimum program size seems to be about 24K.  This is because
	  the compiler generates intermediate code; an interpreter occupies
	  the first 20K or so of every program.  This interpreter does not
	  have to be linked with the program, so the file size can be small,
	  but in this case you have to have the runtime overlay hanging around
	  on your disc in order to run your programs.

	- There is no mechanism for linking assembler programs to the C
	  programs.  There *is* a mechanism for calling assembler programs,
	  though, if you want to load or initialize code into memory
	  somewhere, you can call it.  Kind of like the Atari notion of
	  a BASIC-Assembler interface.

	- The compiler matches reserved words in either-case mode;  you
	  CAN NOT turn this off.  That is, the reserved word "int" can
	  be given as "int", "Int", "INT", etc.  This is the only thing
	  that I think they did really Wrong.

I bought because I hoped that since it generates intermediate code, it would
compile some large programs to fit into my CPM80 system better.  I haven't
proved or disproved this notion yet, but given the horrible code produced
by the Aztec and Ecosoft compilers that I have, I don't doubt that there
is a size threshold above which programs compiled with MIX will be smaller
than with those others. All in all, it seems to be a great buy, especially
if you don't care about speed.

About the MIX editor: I'll restate what I said several months ago.  MIX
seems to have done a great job with this too, but (as with the compiler)
they made one thing Wrong: the editor doesn't deal with control characters.
Like formfeeds and tabs!!  So for me, the editor is useless.  The folks
at MIX say they are going to fix this-- I hope so, because the editor looks
really nice.

Mark Mallett
decvax!sii!mem  or  ittatc!sii!mem
27-Oct-85 07:08:15-MST,1372;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 27 Oct 85 07:08:09-MST
Received: from brl-tgr.arpa by AMSAA.ARPA id a023370; 27 Oct 85 8:37 EST
Received: from usenet by TGR.BRL.ARPA id a004727; 27 Oct 85 8:42 EST
From: "R.Thomas" <rbt%sftig.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Re: Classified ads
Message-ID: <612@sftig.UUCP>
Date: 25 Oct 85 18:44:22 GMT
To:       info-cpm@AMSAA.ARPA

> Eric, there is a bottom line to all this.  If the ads continue, the
> gateway between net.micro.cpm and INFO-CPM will be discontinued.  I
> don't think any of us want to see that.  We ALL gain a lot by the free
> flow of information and ideas between readers on both networks.
> 
> --Keith Petersen

Why can't the gateway be moderated?  This is being done for a lot of
ARPAnet groups as we watch (read net.announce).  The moderator would be
able to forward only those articles from net.micro.cpm that s/he felt were
appropriate.  Needless to say, there is probably much less that originates
on the ARPAnet that  net.micro.cpm readers would be offended by, but that
could be deleted too.

Rick Thomas

PS  I would volunteer to do the moderation, if somebody would fix me up
with an account on an ARPAnet machine that I could get to via a local phone
call...

ihnp4!attunix!rbt
(201)-522-6062
27-Oct-85 12:34:45-MST,973;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 27 Oct 85 12:34:40-MST
Received: from xerox.arpa by AMSAA.ARPA id a023859; 27 Oct 85 14:05 EST
Received: from Flora.ms by ArpaGateway.ms ; 27 OCT 85 11:08:29 PST
From: NBaheti.es@XEROX.ARPA
Date: 27 Oct 85 11:07:28 PST
Subject: Re: Classified ads
In-reply-to: rbt%sftig.uucp@BRL.ARPA's message of 25 Oct 85 18:44:22
 GMT, <612@sftig.UUCP>
To: "R.Thomas" <rbt%sftig.uucp@BRL.ARPA>
cc: info-cpm@AMSAA.ARPA
Message-ID: <851027-110829-1624@Xerox>

I don't think that a moderated system is the answer to the problem. 
On the Xerox system we don't get many (we get a few but not enough to
bothersome) ads because we have mailing lists intended for them a-
lone. There is a JunkMail and WantAds list for those who are interested
in receiving the mail. This is probably the best solution, because it
keeps all parties satisfied.
 
--Arun Baheti
  NBaheti.es@Xerox
27-Oct-85 23:10:40-MST,2226;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 27 Oct 85 23:10:29-MST
Received: from simtel20.arpa by AMSAA.ARPA id a024801; 28 Oct 85 0:40 EST
Date: Sun, 27 Oct 1985  22:43 MST
Message-ID: <WANCHO.12154631273.BABYL@SIMTEL20.ARPA>
From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
To:   INFO-CPM@AMSAA.ARPA, INFO-MICRO@brl.ARPA, ADA-SW@SIMTEL20.ARPA
cc:   INFO-IBMPC@usc-isib.ARPA, INFO-HZ100@radc-tops20.ARPA
Subject: SIMTEL20 Repository Status

Collection Name         # files         # dirs  ~Size(MB)       # Disk Pages

MICRO:<CPM.*>           2,880           124     30.6            16,651
MICRO:<CPMUG.*>         1,923            92     12.8             6,454
MICRO:<SIGM.*>          4,795           205     40.8            21,341
MICRO:<PC-BLUE.*>       3,092           104     27.3            14,694

PS:<ADA.*>                288            28     17.3             8,176

PS:<UNIX.*>               676            26     15.8             7,743

PS:<MAIL.ARCHIVES>        101/14 lists          37.5            13,681

MICRO: is an RP06 disk drive which is full.  We are anticipating the
installation of an RP07 Real Soon Now, along with a TU78 tape drive.
The RP07 has a capacity of almost three times an RP06 and has double
the channel speed.  The TU78 is capable of 6250 bpi.

Shortly after the installation and check out of the RP07, all the
collections listed above, except the mail archives, will be moved to
the RP07, which will be named PD:.  We will then be able to bring the
SIG/M and PC/BLUE collections up-to-date and add others as they become
available.  Look for an announcement of the changeover.

Additions and changes to the CP/M collection are usually announced to
INFO-CPM.  Additions to the SIG/M and PC/BLUE collections are
announced to INFO-CPM, INFO-MICRO, INFO-IBMPC, and INFO-HZ100.

Additions and changes to the Ada collection are announced only to
ADA-SW.  To be added to ADA-SW, send your request to
ADA-SW-REQUEST@SIMTEL20.

Additions and changes to the Unix collection will be announced to a
new list named UNIX-SW.  To be added to UNIX-SW, send your request to
UNIX-SW-REQUEST@SIMTEL20.

--Frank
28-Oct-85 05:24:12-MST,1217;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 28 Oct 85 05:24:00-MST
Received: from brl-aos.arpa by AMSAA.ARPA id a025549; 28 Oct 85 6:57 EST
Received: from simtel20.arpa by AOS.BRL.ARPA id a000335; 27 Oct 85 0:36 EDT
Date: Sat, 26 Oct 1985  22:16 MDT
Message-ID: <KPETERSEN.12154353173.BABYL@SIMTEL20.ARPA>
Sender: KPETERSEN@SIMTEL20.ARPA
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
To:   Info-Cpm@BRL.ARPA
Subject: PDSE067A.LQT phone list of XMODEM protocol systems updated

The latest list of all known RCPM (Remote CP/M) systems and other
systems supporting XMODEM protocol file transfers is now available
from SIMTEL20 and has been posted to Usenet's net.micro.cpm.  If you
cannot FTP and you are not already on the list to automatically
receive updates of this phone list, please send a note to me and I'll
add you to the mailing list.

Filename			Type	 Bytes	 CRC

Directory MICRO:<CPM.MISC>
PDSE067A.LQT.1			BINARY	 45952  061BH

--Keith Petersen
Arpa:  W8SDZ@SIMTEL20.ARPA
uucp:  ...!seismo!SIMTEL20.ARPA!W8SDZ
uucp:  ...!{decvax,unc,hao,cbosgd,seismo,aplvax,uci}!brl-bmd!w8sdz
uucp:  ...!{ihnp4!cbosgd,cmcl2!esquire}!brl-bmd!w8sdz
28-Oct-85 05:38:35-MST,2452;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 28 Oct 85 05:38:21-MST
Received: from mitre.arpa by AMSAA.ARPA id a025747; 28 Oct 85 7:05 EST
Received: by mitre.ARPA (4.12/4.7)
	id AA12533; Sun, 27 Oct 85 20:37:57 est
Message-Id: <8510280137.AA12533@mitre.ARPA>
To: Boebert@MIT-MULTICS.ARPA
Cc: Boebert@HI-MULTICS.ARPA, info-cpm@AMSAA.ARPA
Subject: Re: Accounting and Database pkg needed
In-Reply-To: Your message of Fri, 25 Oct 85 16:52 EDT.
	     <851025205207.962693@MIT-MULTICS.ARPA>
Date: 27 Oct 85 20:37:38 EST (Sun)
From: Jeff Edelheit <edelheit@MITRE.ARPA>

I spent a lot of time and energy trying to find a package similar to what you
have described for my synagogue (there are a lot of similarities between
a church and synagogue package.)  Bottom line was that the one's I found
were generally written for MS/PC-DOS and that the affordable ones ($2,500 or
less) weren't very good.  (My congregation felt they couldn't afford more
than $2,500.  There are some packages for $3,000 and more but I didn't
bother to look.)

Since there is a market for a relatively good package at a reasonable price,
I decided to write one.  (Maybe I should say integrate one.)  I am using 
the Micro Business Applications (MBA) Accountant Series (G/L, A/P, A/R)
and dBaseIII.  I am using dBase for membership data (Name, address, phone #,
children's names, birthdates, youth group activity) and for some billing 
data.  I am writting some dBase code generate some monthly, quarterly,
semi-annual and annual billing data.  This data is passed to the MBA A/R
for statement generation, account aging, and G/L posting.  Since we have
about 50 employees (school teachers, custodians, office staff) we are using
MBA's payroll system.  (It passes data to the G/L).

All of the MBA software was originally written for CP/M-80 systems and was
then ported to PC/MS-DOS.  It has a pretty-good user interface and the 
documentation is really complete.  I chose dBaseIII for two reasons:
the "Assist" program makes it easier for the novice to generate queries,
reports and address labels; and the MBA software included a conversion
utility to go between the MBA files and dBase II/III.  I am not suggesting
that my choices were the best; they just seem to work fairly well and 
you can't ask for much more.

Hope this was helpful.

Regards,

Jeff Edelheit
(edelheit@mitre)



28-Oct-85 06:13:07-MST,759;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 28 Oct 85 06:13:02-MST
Received: from brl-tgr.arpa by AMSAA.ARPA id a026550; 28 Oct 85 7:45 EST
Received: from usenet by TGR.BRL.ARPA id a017329; 28 Oct 85 7:47 EST
From: Tom Nadas <tom%utcsri.uucp@BRL.ARPA>
Newsgroups: net.micro,net.micro.cpm
Subject: Re: KAYPRO to TELEVIDEO?
Message-ID: <1542@utcsri.UUCP>
Date: 27 Oct 85 19:09:52 GMT
Xref: seismo net.micro:13210 net.micro.cpm:5195
To:       info-cpm@AMSAA.ARPA


Oh, the arrogance of the MS-DOS world!  Both Uniform and Media Master
were invented for CP/MM, then ported to MS-DOS.  
-- 

					Tom Nadas

UUCP:   {decvax,linus,ihnp4,uw-beaver,allegra,utzoo}!utcsri!tom
CSNET:  tom@toronto
28-Oct-85 10:53:53-MST,1549;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 28 Oct 85 10:53:46-MST
Received: from office-1.arpa by AMSAA.ARPA id a008466; 28 Oct 85 12:15 EST
Date: 28 Oct 85 09:15 PST
From: Alan Bomberger <ACB.COR@OFFICE-1.ARPA>
Subject: Is CP/M dead
To: info-cpm@AMSAA.ARPA
Message-ID: <COR-ACB-7Y61J@OFFICE-1>

I join those who believe in CP/M.  Not that it is the greatest etc, but because
it is functional, simple, and predictable.  I have done some rather 
sophisitcated things for CP/M including POP UP windows and ThinkTank like 
things.  But people are killing it.  The users are killing it.  How?

Simple.  As a commercial CP/M developer and vendor I find that it is nearly 
impossible to find any publication read by the "2 million" CP/M users.  While 
there are many publications that CP/M users read most of them are dominated by 
"IBM" users.  Advertising rates are based on total circulation and thus 
advertising for the 3% of the CP/M readers is prohibitive.  This applies to 
distributors as well who must examine their advertising costs.  So since the 
publishers killed off the likes of Microsystems there is no central place to 
advertise new CP/M software.

I am sorry if that sounds like a very commercial reason and I would surely 
appreciate feedback.  I find it frustrating.  CP/M users should rally behind 
some publication and boost its readership to 500,000 CP/M readers.  That ought 
to create the atmosphere for developers to reach the "2 million" users.

28-Oct-85 12:27:32-MST,903;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 28 Oct 85 12:27:22-MST
Received: from wsmr08.arpa by AMSAA.ARPA id a011116; 28 Oct 85 13:24 EST
Date: Mon, 28 Oct 85 11:23:57 MST
From: John Gilbert CD <jgilbert@WSMR08.ARPA>
Subject: Re: Is CP/M dead
In-Reply-To: Your message of 28 Oct 85 09:15 PST
To: Alan Bomberger <ACB.COR@OFFICE-1.ARPA>
Cc: info-cpm@AMSAA.ARPA

I think Alan's message raises a matter of great concern to the users of CPM...
there simply is no magazine that deals principally with CPM matters and hence
can create a forum for information exchange concerning it.

I was startled to learn recently that KayPro's magazine Profiles, with 100,000
circulation is that largest magazine appealing mostly to CPM users and it is
undergoing an identity crisis since KayPro is no selling MS-DOS based
computers.

John Gilbert

28-Oct-85 12:54:41-MST,1445;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 28 Oct 85 12:54:33-MST
Received: from xerox.arpa by AMSAA.ARPA id a011249; 28 Oct 85 13:28 EST
Received: from Salvador.ms by ArpaGateway.ms ; 28 OCT 85 10:30:13 PST
Sender: "Philip M. Burton.osbunorth"@XEROX.ARPA
Date: 28 Oct 85 10:17:00 PST (Monday)
Subject: Re: Is CP/M Dead (or) Turbo buy fun
From: Burton.osbunorth@XEROX.ARPA
To: wancho@SIMTEL20.ARPA, ABN.ISCAMS@USC-ISID.ARPA
cc: rbloom@APG-1.ARPA, info-cpm@AMSAA.ARPA
In-Reply-to: ABN.ISCAMS%USC-ISID:ARPA:Xerox's message of 26-October-85
 (Saturday) 3:03:46 PDT -
Reply-to: Burton.osbunorth@XEROX.ARPA
Message-ID: <851028-103013-2190@Xerox>

Dave,

I think you're pretty much right, at least for us unrepentant and
unreconstructed hackers.  But for my wife, DOS is better, because the
bigger memory space of a 16 bit system makes for "friendlier" programs.
And my wife is part of that great mass market that will buy a machine
with 3 initials on it because they feel good about those three initials
(beats me why, with Compupro's around, but that's another story).  

Even CP/M 86, had it caught on, would have been better than CP/M 80 for
this reason.  

If Gary Kildall made only one mistake, it was in putting work into an
8-bit operating system, and not the 16 -bit version.  Thus, he wasn't
ready when IBM *wanted* to use CP/M 86.

Sigh ...

Phil Burton
28-Oct-85 14:08:25-MST,735;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 28 Oct 85 14:08:19-MST
Received: from mitre.arpa by AMSAA.ARPA id a016375; 28 Oct 85 15:41 EST
Received: by mitre.ARPA (4.12/4.7)
	id AA21318; Mon, 28 Oct 85 15:14:18 est
Date: Mon, 28 Oct 85 15:14:18 est
From: Thomas Reid <treid@mitre.ARPA>
Message-Id: <8510282014.AA21318@mitre.ARPA>
To: info-pascal@brl.ARPA
Subject: Borland Modula-2 ???
Cc: info-cpm@AMSAA.ARPA

Since early Summer, we have heard that Borland has had a Turbo?Modula-2 in
beta test for CP/M-80 with MSDOS not too far behind.  Does anyone know when
the little devil will be finally unleashed?  Anyone have the latest poop?
Care to share it?  Thanks.  Tom.
28-Oct-85 14:34:21-MST,636;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 28 Oct 85 14:34:06-MST
Received: from lll-mfe.arpa by AMSAA.ARPA id a016946; 28 Oct 85 16:05 EST
Date: Mon, 28 Oct 85 14:03 PST
From: Maron@LLL-MFE.ARPA
Subject: Is CP/M dead?
To: info-cpm@AMSAA.ARPA


For those looking for a publication to rally behind consider MicroCornucopia
of Bend (I think) Oregon.  I've been reading it since issue#1 and think it is
great.  It too is suffering from what's next but has not made any firm 
decisions.  It looks like a good place to advertize since it is a Z80 (+others)
magazine.
--Neil
28-Oct-85 17:30:58-MST,1017;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 28 Oct 85 17:30:46-MST
Received: from usc-isi.arpa by AMSAA.ARPA id a018953; 28 Oct 85 18:42 EST
Date: 28 Oct 1985 18:39:13 EST
Subject: Re: Borland Modula-2 ???
From: Rex Buddenberg <BUDDENBERGRA@USC-ISI.ARPA>
To: Thomas Reid <treid@MITRE.ARPA>
cc: BUDDENBERGRA@USC-ISI.ARPA
In-Reply-To: <8510282014.AA21318@mitre.ARPA>
ReSent-Date: 28 Oct 1985 18:45:14 EST
ReSent-From: Rex Buddenberg <BUDDENBERGRA@USC-ISI.ARPA>
ReSent-To: info-cpm@AMSAA.ARPA
ReSent-cc: BUDDENBERGRA@USC-ISI.ARPA

Regarding Borland Modula-II, I called them last week after a long
period of silence.  The answer I got was 'next week -- we just got the
manual back from the printer.  What format disc do you want it on?'
This is the beta, not the release.

An aside, re the 'is CPM dead -- when I said I wanted mine on 8" CPM,
I got a long pause!  Then 'Can you read anything else?'  Alas...
Rex
BUDDENBERGRA@USC-ISI.ARPA
-------
28-Oct-85 20:59:32-MST,568;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 28 Oct 85 20:59:27-MST
Received: from mit-xx.arpa by AMSAA.ARPA id a020342; 28 Oct 85 22:22 EST
Date: Mon 28 Oct 85 22:26:29-EST
From: Sangho Yoon <ID.YOON@MIT-XX.ARPA>
Subject: C128 CP/M
To: info-cpm@AMSAA.ARPA
Message-ID: <12154868437.36.ID.YOON@MIT-XX.ARPA>


Is there anyone out there with a Commodore 128 using CP/M ?  I would like
to know where I can get software for it.  Any help would be appreciated.


			Sangho Yoon
			ID.YOON@MIT-XX
	
-------
28-Oct-85 21:17:23-MST,944;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 28 Oct 85 21:17:14-MST
Received: from simtel20.arpa by AMSAA.ARPA id a020477; 28 Oct 85 22:48 EST
Date: Mon 28 Oct 85 20:52:36-MST
From: Rick Conn <RCONN@SIMTEL20.ARPA>
Subject: ZCPR3 Newsletters
To: info-cpm@AMSAA.ARPA
Message-ID: <12154873191.17.RCONN@SIMTEL20.ARPA>

In MICRO:<CPM.Z3NEW>:
	Z3NEWS.305, .3Q5, .306, .3Q6 - vols 305 and 306 of the
Echelon newsletters

In MICRO:<CPM.ZCPR3>:
	Z3NEWS.3Q5, .3Q6 - same (only in squeezed form)

Somewhere along the line I dropped the file for vol 304.  Will look
it up.  Of some particular interest is a brief description of another HD64180
board: S-100 bus, HD64180, 64K-256K Static RAM, 2 RS-232 drivers, Master/Slave.
So now there are 2 64180 boards out.  Lots of other items in this newsletter,
including a list of people working on software for the Z System.

	Rick
-------
28-Oct-85 22:41:33-MST,5861;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 28 Oct 85 22:41:16-MST
Received: from simtel20.arpa by AMSAA.ARPA id a020949; 29 Oct 85 0:15 EST
Date: Mon 28 Oct 85 22:18:50-MST
From: Rick Conn <RCONN@SIMTEL20.ARPA>
Subject: Re: Is CP/M Dead (or) Turbo buy fun
To: rbloom@APG-1.ARPA
cc: info-cpm@AMSAA.ARPA
In-Reply-To: Message from "Robert Bloom AMSTE-TEI 3775 <rbloom@apg-1.ARPA>" of Fri 25 Oct 85 14:32:19-MDT
Message-ID: <12154888891.11.RCONN@SIMTEL20.ARPA>

Hello, Bob,

	"Is CP/M Dead?" is a matter of perspective, as I see it.  It also
depends on what you mean by "Dead."  I offer the following:

Meaning of "Is CP/M Dead?"			Answer to "Is CP/M Dead?"
--------------------------			-------------------------
1. Is anyone making commercial software 	No, CP/M is not dead; there
 packages for CP/M now?				 are many new commercial
						 packages out there (1)

2. Are the majority of the users of all		I don't know, but I think
 microcomputers running CP/M?			 50/50 chance that IBM has
						 not reached 2 Million users;
						 but how many old CP/M users
						 switched to IBM?

3. Are new users of microcomputers buying	Yes, the new users are largely
 CP/M systems (counting derivatives)?		 buying IBM, so CP/M is dying
 (this refers to personal computer users)	 if not already dead

4. Are total sales of new microcomputers	I don't know, but I am aware
 leaning toward CP/M (counting derivatives)?	 of many, many embedded micros
 (this refers to PCs and embedded computers)	 running CP/M et al

5. Is the flow of public domain CP/M software	No, as is evidenced by the
 stopping?					 latest SIG/M releases I saw
						 today, CP/M is still thriving

6. Where is the majority of the public domain	No, CP/M is not dead; looking
 software?					 at the libraries, CP/M is
						 first, IBM is second; but how
						 do the "good/junk" ratios
						 compare?
--------------
(1) Some examples of new commercial packages for CP/M (or Z System):
	What				Author			Sold by
	----				------			-------
Z-MSG (Electronic Mail)			Tim Gary		Echelon
ZAS (Z80/HD64180 Assembler)		Patrick O'Connell	Mitek
DSD (Dynamic Screen Debugger)		John Otken		Soft Advances
ZDM (Z80/HD64180 Debugger)		Robert Doolittle	Echelon
ITOZ/ZTOI Assembly Code Translators	Robert Doolittle	Echelon
ZRDOS (Z System BDOS Replacement)	Dennis Wright		Echelon
REVAS (Disassembler)			Al Hawley		REVASCO
DISCAT (Disk Catalog System)		Richard Conn		Echelon
TERM III (Communications System)	Richard Conn		Echelon
MIX C Compiler				MIX Software		...
MIX Editor				MIX Software		...
KAMAS (Outline Processor)		KAMASOFT, Inc		...
Write-Hand Man				Poor Person Software	...
REL/MAC (REL-to-source translator)	MicroSmith Computer Tech  ...
HiSoft C				HiSoft			...
HiSoft Pascal				HiSoft			...
DateStamper				Plu*Perfect Systems	...
ConIX Operating System			Computer Helper Industries, Inc ...
RED Editor				Edward K. Ream		...
Z80ASM (Assembler)			SLR Systems		...
MEX Communications Program		Ron Fowler		NightOwl

[I'm sure I left someone out - data is from the Echelon Newsletters and
 the latest issue of Dr Dobbs; also, "..." above means the same as the
 author; apologies to anyone I excluded]

------------

	So, the above sums up my response to your question.  If you look
at the "new user" community, the answer is what you expected - Yes, CP/M is
dead since the majority of new PC users are not buying it (my meaning 3 above).
There are lots of applications, especially embedded applications, where a Z80
running CP/M is a marvelous, simple, and cheap solution (try embedding an IBM
PC in a communications controller, if you see what I mean).  In the other
four categories, the issue is not at all clear.  CP/M (and the Z System)
is certainly alive as I see it.

	As for myself, I am running ZCPR3/ZRDOS and do not intend to switch
at home.  This combination meets my needs nicely.  At work, I use TIPCs
(IBM workalikes), and I have no complaints, but I don't do anything there
that I can't do at home.  I write code in assembly language and C at home,
and exclusively in C at work (except on the VAX, where I write exclusively
in Ada, and the VAX 11/785 makes a nice PC when working with Ada).

	My next hardware move is to upgrade to an S-100, 64180 board
(one is out now).  I plan to follow that with more software, particularly
a multi-tasking ZCPR4 with a large TPA.  After that, I will probably move
to a good, very fast UNIX system (68020, 32032 class).  Essentially, I plan
to skip the IBM PC market entirely ... if I need a powerful processor, I'll
go with one backed by a good operating system.

	For further discussions, see Jerry Pournelle's column in the
November "Byte" and the "Of Interest" column by Alex Ragen in the November
"Dr. Dobb's Journal."  Quoted from Alex' column:

	"Electronic Business, a magazine devoted to the dollars and
cents issues of the computer business, recently published a long article
analyzing the microprocessor market.  It carried the surprising message
that 8-bit processors make up by far the lion's share of that market,
with 16-bit processors trailing far behind.  Moreover, most industry
observers expect this situation to continue for many years.  The reason
is that the now inexpensive 8-bit processors and their peripherals are
perfectly adequate for most applications.  Where 16-bit processors hold
sway is in the prestige conscious world of the personal computer, where
only the latest fashion is marketable."

		Rick Conn

Disclaimer: While affiliated with Echelon (and thereby Hitachi [makers
of the 64180] and many others on the above list), this text expresses
my personal opinions and is not intended to be an advertisement or the
opinions of anyone else.
-------
29-Oct-85 01:00:06-MST,3083;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 29 Oct 85 00:59:55-MST
Received: from brl-aos.arpa by AMSAA.ARPA id a021227; 29 Oct 85 2:32 EST
Received: from dca-eur.arpa by AOS.BRL.ARPA id a000764; 29 Oct 85 2:34 EST
Date: 29 Oct 85 06:59:26 GMT
From: bower@DCA-EUR.ARPA
Subject: Re: CPM and Modula et al
To: info-cpm@BRL.ARPA
CC: info-pascal@brl-voa


   In response to the "Is CPM dead issue", Consider the quality of newer
programs and tools coming out now.  This little OS and its derivative,
ZRDOS, are really entering maturity.  EFFICIENT tools are becoming avail-
able as evidenced by newer languages like Modula-2, which in the case of a
recent issue of Computer Languages (I think) comparing a pre-release of
Borland's Modula-2, Hochstrasser's Modula-2 (Which I use, and distributed
by Workman & Associates in the US), and three systems for MS-DOS.  The 8-
bitters under CPM compared VERY favorably to the MS-DOS systems.

   The ease of tailoring CP/M systems to specific applications while not
destroying compatibility should not be overlooked.  I have a system that
adapts to nearly any disk format by coding the disk layout on track 0,
sector 1 in single-density.  I can therefore play around with things like
skew factors and physical sector sizes.  Why be locked into 4.5 kb per
track on a 5"disk when room exists for a full 5 k per track.  The Ampro
little boards and SB-180 can provide very graphic examples of high-perfor-
mance systemsd managed by a flexible and capable OS like CP/M.

   A while ago, a round-table discussion occured here on the "ideal CP/M
environment".  I contend that the current state of CP/M has advanced even
more in the past year.  The problem, as one contributor mentioned, is that
the information is not getting out to the masses.  Consider the following:

        DateStamper - Adds real-time or pseudo-time and date capability to
                CP/M systems.  It stays resident after loading and occupies
                less than 1k.  I have used it  for quite a while in both
                below CCP and above-BIOS locations, and have found NO glitches.

        Mix Editor - I don't have this program, but the ads say it supports
                split-screen and dual-file editting, such as the touted
                "cut-and-paste" capability of "larger" machines.

        Hochstrasser Modula-2 - Very efficient code generation, adaptable
                to run-time CP/M machine, supports shared data areas needed
                for overlays, chaining, etc.

        Dazzlestar - Available from Simtel20.  Screen-oriented disassembler.
                This is an amazingly friendly disassembler, with a non-standard
                .MAC output format, but very capable.

   Eventually, I am sure that knowledge of MS-DOS may be required, but I keep
hoping that something offering the flexibility, capability, and efficiency of
CP/M will displace it before that time.  (Hope springs eternal...etc).
                Hal

29-Oct-85 06:18:10-MST,840;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 29 Oct 85 06:18:03-MST
Received: from usc-eclb.arpa by AMSAA.ARPA id a022830; 29 Oct 85 7:49 EST
Date: 29 Oct 1985 04:53-PST
Sender: STANLEY@USC-ECLB.ARPA
Subject: Is CP/M Dead?
From: STANLEY@USC-ECLB.ARPA
To: info-cpm@AMSAA.ARPA
Message-ID: <[USC-ECLB.ARPA]29-Oct-85 04:53:57.STANLEY>


Another possible rallying point for CP/Mers is the First Osborne
Group's FOGHORN.  While there is obviously a noticeable Osborne
bias, most of what is presented is plain vanilla CP/M application
stuff.  I seem to remember its current circulation is around
20,000, and it attracts a large number of CP/M advertisers.  I've
used much of the stuff in there on both my Osborne and on my two
H89's.

                                ...Dick

29-Oct-85 09:48:09-MST,781;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 29 Oct 85 09:48:02-MST
Received: from xerox.arpa by AMSAA.ARPA id a029926; 29 Oct 85 11:11 EST
Received: from Muscat.ms by ArpaGateway.ms ; 29 OCT 85 08:11:26 PST
Date: Tue, 29 Oct 85 11:11 EST
From: Kushall.henr@XEROX.ARPA
Subject: Re: C128 CP/M
In-reply-to: <12154868437.36.ID.YOON@MIT-XX.ARPA>
To: Sangho Yoon <ID.YOON@MIT-XX.ARPA>
cc: info-cpm@AMSAA.ARPA
Message-ID: <851029-081126-1339@Xerox>

Most of the Osborne and Kaypro and generic software should run on the
C128.
When you order SW specify the Osborne or Kaypro formats the 128 can read
both.

I have a DEC Rainbow and wrote out XLISP on Osborne format for a friend
with a C128 and it worked fine.

Ed

30-Oct-85 01:12:25-MST,927;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 30 Oct 85 01:12:19-MST
Received: from brl-tgr.arpa by AMSAA.ARPA id a011131; 30 Oct 85 2:40 EST
Received: from usenet by TGR.BRL.ARPA id a023652; 30 Oct 85 2:41 EST
From: dbmk1%stc.uucp@BRL.ARPA
Newsgroups: net.micro,net.micro.cpm
Subject: Re: KAYPRO to TELEVIDEO?
Message-ID: <674@stc-b.stc.UUCP>
Date: 29 Oct 85 10:27:35 GMT
Xref: seismo net.micro:13218 net.micro.cpm:5210
Xpath: stc stc-b stc-b stc-a
To:       info-cpm@AMSAA.ARPA

In article <1542@utcsri.UUCP> tom@utcsri.UUCP (Tom Nadas) writes:
>
>Oh, the arrogance of the MS-DOS world!  Both Uniform and Media Master
>were invented for CP/MM, then ported to MS-DOS.  

Great, wonderful even,  so who sells the damn things for CP/M 80.??


-- 


Regards
  Derek

!seismo!mcvax!ukc!stc!dbmk1

I've heard that re-incarnation is making a come-back.
30-Oct-85 20:25:41-MST,1206;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 30 Oct 85 20:25:34-MST
Received: from brl-aos.arpa by AMSAA.ARPA id a000185; 30 Oct 85 19:43 EST
Received: from simtel20.arpa by AOS.BRL.ARPA id a000444; 30 Oct 85 17:02 EST
Date: Wednesday, 30 October 1985  07:50-MST
Message-ID: <KPETERSEN.12155332984.BABYL@SIMTEL20.ARPA>
Sender: "B.Eiben LCG Ext 617-467-4431" <EIBEN@DEC-MARLBORO.ARPA>
From: "B.Eiben LCG Ext 617-467-4431" <EIBEN@DEC-MARLBORO.ARPA>
Subject:   DEARC - Generic TurboPascal pgm unpacks .ARC files
ReSent-From: KPETERSEN@SIMTEL20.ARPA
ReSent-To: Info-Cpm@BRL.ARPA
ReSent-Date: Wed 30 Oct 1985 14:58-MST

DEARC.PQS, a generic Turbo V3 routine which unpacks .ARC files, (ARC
is a utility widely used on FIDO bulletin boards to pack files
together), has been uploaded to SIMTEL20 as:

Filename			Type	 Bytes	 CRC

Directory MICRO:<CPM.TURBOPAS>
DEARC.PQS.1			BINARY	 11904  89D3H

Up to now, we CPM people have been stuck having to skip any .ARC
files. No longer!!!! The utility should be compiled and run passing
the .ARC filename as the p1 parameter.

Al Hull

   ========

			Thanks Al - that was sorely needed...
30-Oct-85 21:12:36-MST,1346;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 30 Oct 85 21:12:29-MST
Received: from brl-tgr.arpa by AMSAA.ARPA id a000729; 30 Oct 85 22:38 EST
Received: from usenet by TGR.BRL.ARPA id a015394; 30 Oct 85 22:40 EST
From: brown%nicmad.uucp@BRL.ARPA
Newsgroups: net.micro,net.micro.pc,net.micro.cpm
Subject: Re: Latest YMODEM.DOC revision available
Message-ID: <406@nicmad.UUCP>
Date: 30 Oct 85 23:38:51 GMT
Xref: seismo net.micro:13225 net.micro.pc:6170 net.micro.cpm:5212
To:       info-cpm@AMSAA.ARPA

In article <244@omen.UUCP> caf@omen.UUCP (Chuck Forsberg WA7KGX) writes:
[that YMODEM.DOC is available]

I have downloaded it into the NICBUL RBBS system.  You can also call
(608) 273-5037 between 6pm to 8am M-F or all day on weekends CST.
Baud rate is 300/1200/2400.

File you will need is:
	YMODEM.ARC

If you don't have the arc program, get:
	ARC430.EQE
	ARC430.DQC

Someone also upload a YAM demo program:
	YAMDEMO2.ARC

When you call the system use USE as the first name, NET as the last name
and UUCP as the password.  That will give you plenty of time to download
all of the programs (at 1200 or 2400). 

I am the SYSOP, so if you have any problems, let me know, either here or on
the BBS.
-- 

Mr. Video   {seismo!uwvax!|!decvax|!ihnp4}!nicmad!brown
31-Oct-85 05:53:48-MST,1726;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 31 Oct 85 05:53:40-MST
Received: from usc-eclb.arpa by AMSAA.ARPA id a002988; 31 Oct 85 7:28 EST
Date: 31 Oct 1985 04:32-PST
Sender: STANLEY@USC-ECLB.ARPA
Subject: Re: KAYPRO to TELEVIDEO?
From: STANLEY@USC-ECLB.ARPA
To: dbmk1%stc.uucp@BRL.ARPA
Cc: info-cpm@AMSAA.ARPA
Message-ID: <[USC-ECLB.ARPA]31-Oct-85 04:32:30.STANLEY>
In-Reply-To: <674@stc-b.stc.UUCP>

	
    Received: from AMSAA.ARPA by USC-ECLB.ARPA; Wed 30 Oct 85 00:17:21-PST
	      from brl-tgr.arpa by AMSAA.ARPA id a011131; 30 Oct 85 2:40 EST
	      from usenet by TGR.BRL.ARPA id a023652; 30 Oct 85 2:41 EST
    Date: 29 Oct 85 10:27:35 GMT
    From: dbmk1%stc.uucp@BRL.ARPA
    To:       info-cpm@AMSAA.ARPA
    Subject: Re: KAYPRO to TELEVIDEO?
    Return-Path: <info-cpm-request@AMSAA>
    Message-ID: <674@stc-b.stc.UUCP>
    Newsgroups: net.micro,net.micro.cpm
    Xref: seismo net.micro:13218 net.micro.cpm:5210
    Xpath: stc stc-b stc-b stc-a
    
    In article <1542@utcsri.UUCP> tom@utcsri.UUCP (Tom Nadas) writes:
    >
    >Oh, the arrogance of the MS-DOS world!  Both Uniform and Media Master
    >were invented for CP/MM, then ported to MS-DOS.  
    
    Great, wonderful even,  so who sells the damn things for CP/M 80.??
    
    
    -- 
    
    
    Regards
      Derek
    
    !seismo!mcvax!ukc!stc!dbmk1
    
    I've heard that re-incarnation is making a come-back.
    
	      --------------------
		
Derek:

Media Master can be obtained (for CP/M-80) from its writers, DG
Systems.  The First Osborne Group used to (and may still) sell
Uniform for CP/M.

                        ...Dick
31-Oct-85 10:38:44-MST,1171;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 31 Oct 85 10:38:36-MST
Received: from eglin-vax.arpa by AMSAA.ARPA id a013568; 31 Oct 85 11:54 EST
Date: 29 Oct 85 14:28:00 CDT
From: "UV2::FERRILL" <ferrill@uv2.decnet>
Subject: 8" Drives for Apple ][ CP/M
To: info-cpm <info-cpm@AMSAA.ARPA>
Reply-To: "UV2::FERRILL" <ferrill@uv2.decnet>

Help...  I just found an add from a company that has an 8" floppy controller
for the Apple for $29.95!!  I called the toll free number and the guy says
that he has a controller with schematic but no software.  The board uses
a WD1793 controller chip and has CORVUS etched on the board.  He also says
that all calls by others to CORVUS produced the response of "Never heard of
a 8" controller board for the Apple".  Anyway, does anyone have any experience
with writing drivers for the Apple and PCPI CP/M??  I might take a chance
for 30 bucks if I knew I could get some help with the software.
                              Thanks in advance

                                       Paul Ferrill
                                       ferrill@eglin-vax.arpa

------
31-Oct-85 13:31:37-MST,1312;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 31 Oct 85 13:31:29-MST
Received: from brl-tgr.arpa by AMSAA.ARPA id a019834; 31 Oct 85 14:52 EST
Received: from usenet by TGR.BRL.ARPA id a001193; 31 Oct 85 14:08 EST
From: Blackwell <mdb%aicchi.uucp@BRL.ARPA>
Newsgroups: net.micro.cpm
Subject: Perfect Filer question
Message-ID: <594@aicchi.UUCP>
Date: 30 Oct 85 01:38:04 GMT
To:       info-cpm@AMSAA.ARPA

[-----------------]

I am posting this message for a friend.  Mail responses to me at
    ihnp4!aicchi!mdb
---

  We are having a problem with Perfect Filer running on a Kaypro with
a 10M hard disk.  When we delete a record, the index goes away as it 
should. However, the record is still in the database, and is printed 
when we print our reports.  We have tried to get around this temporarily
by creating a 'deleted' field in the record, but the 'deleted' records 
still take up space (of course) and there seems to be no way of copying
only selected records from one database to another.
  Any ideas on what we are missing (or the program is lacking), or 
suggestions on ways to get around this (a BASIC program maybe?) would
be greatly appreciated.

---

   Thanks for your help!    Mike Blackwell

	ihnp4!aicchi!mdb
---
31-Oct-85 13:58:44-MST,974;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 31 Oct 85 13:58:34-MST
Received: from simtel20.arpa by AMSAA.ARPA id a019926; 31 Oct 85 14:56 EST
Return-Path: <@RADC-TOPS20.ARPA:forwarder@CSNET-SH.ARPA>
Received: from RADC-TOPS20.ARPA by SIMTEL20.ARPA with TCP; Sat 26 Oct 85 19:07:29-MDT
Received: from CSNET-SH.ARPA by RADC-TOPS20.ARPA with TCP; Sat 26 Oct 85 21:02:53-EDT
To: INFO-HZ100@RADC-TOPS20.ARPA
cc: mooers@CSNET-SH.ARPA
Subject: Ram Disk for CP/M on HZ100 ??
Date: 26 Oct 85 20:55:38 EDT (Sat)
From: "Charlotte D. Mooers" <mooers@CSNET-SH.ARPA>
ReSent-Date: Thu 31 Oct 85 12:50:33-MST
ReSent-From: Dick Dysart <RDYSART@SIMTEL20.ARPA>
ReSent-To: info-cpm@AMSAA.ARPA
ReSent-Message-ID: <12155571868.6.RDYSART@SIMTEL20.ARPA>

I would like very much to get hold of a ram disk program for the
CP/M side of the HZ100.  Does such a thing exist?
(I know about RAMDISK for MS-DOS.)

---Charlotte Mooers
31-Oct-85 14:23:10-MST,4755;000000000000
Return-Path: <info-cpm-request@AMSAA.ARPA>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 31 Oct 85 14:22:51-MST
Received: from brl-aos.arpa by AMSAA.ARPA id a020972; 31 Oct 85 15:14 EST
Received: from simtel20.arpa by AOS.BRL.ARPA id a015545; 31 Oct 85 14:48 EST
Date: Thu, 31 Oct 1985  12:47 MST
Message-ID: <KPETERSEN.12155571248.BABYL@SIMTEL20.ARPA>
Sender: KPETERSEN@SIMTEL20.ARPA
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
To:   Info-Cpm@BRL.ARPA
Subject: SD102 Super Directory program now available

The latest verion of SD, the "Super Directory" program, is now
available from SIMTEL20 as:

Filename			Type	 Bytes	 CRC

Directory MICRO:<CPM.DIRUTL>
SD102.LBR.1			BINARY	 77952  BCA1H

SD displays the directory of a CP/M disk, sorted alphabetically, with
the file size in k, rounded to the nearest CP/M block size.  Also
displays library files with the file size in k if the '$L' option is
used.  This version can be assembled with ASM, LASM, MAC, RMAC or M80.

Latest revision:

10/31/85  Fixed bug which caused system to crash if BYE low (LOWCCP)
  v102    and using disk options (DOPT EQU YES).  Thanks to Wayne
          Masters for reporting it.
                                        - Keith Petersen, W8SDZ

Current versions of SD automatically adjust for any block size and
directory length under CP/M 1.4 or 2.x or MP/M (any version).  They
also automatically adjust for any number of disk drives and work
satisfactorily even if no disk is in that drive at the moment.
Provisions are made for:

        (1) automatic pauses when the screen fills up
        (2) searching individual or multiple drives and/or user areas
        (3) unconditional or optional resetting the disk system before
            execution begins
        (4) directing output to a disk file called SD.DIR and appending
            to that file on subsequent runs
        (5) summary line output giving drive and user information,
            number of files matched and how much space they consume,
            and the amount of free space remaining on the disk
        (6) displaying or suppressing "system" files
        (7) accepting ambiguous filenames with or without a drive name
        (8) printer output
        (9) optional help menu with $?

Previous revisions:

10/28/85  Added an equate to allow display of file attributes only in
  v101    inverse video.  This leaves the header line in normal video
          and avoids that bright band on the screen.  Also, with the
          THREBYT equate set, the third byte was written to the disk
          when the F option was active.  This mod fixes that problem.
                                        - Barron McIntire

07/24/85  Rewrote the TIMEON code to allow use of the existing time-
  v100    on-system data contained in BYE5, BYE3, BYE+ or MBYE's RTC
          buffer.  If TIMEON is YES, SD merely reports "Time on system
          is nnn minutes" and makes no attempt to log the user off.
          Logoff responsibility is delegated to the (M)BYE(+) program.
          TIMEON checks to see if BYE is running and continues without
          reporting time-on if not.  No installation required to use
          this feature if you have clock code installed in your BYE.
          All page-1 equates previously used by TIMEON were deleted.
          This update also contains the SD99.FIX code for nested IF'
                                        - Wayne Masters, Potpourri

07/11/85  Added THREBYT equate for systems needing a 3-byte sequence
  v99     for reverse video.    If THREBYT is YES then the value coded
          at TBYTE is added to the reverse video sequence (currently
          set for a Kaypro).  Also added a new "?" option which will
          display a menu of the $ options available if HELP is YES.
                                        - Steve Sanders

03/15/85  Fixes obscure display bug which deletes display of 1, 2 or
  v98     3 file names in 3 out of 4 cases when the directory has
          >255 entries.  The fix code was written by Peter Lyman.
                                        - Paul Foote

01/21/85  Added support for ZRDOS.  Although CP/M compatible, ZRDOS
  v97     does not allow the SWAPEM technique of poking local values
          into the operating system.   Instead, a test for ZRDOS is
          made and, if present, further calls to CPM: set the Warm
          Boot Trap in ZRDOS.  On any error detected by ZRDOS the
          trap is reset and control is passed to DSKERR:  No equates
          need be changed for CPM/ZRDOS, testing is dynamic in the
          run-time code.
                                        - Joe Wright


--Keith
